Subject: Some architecture changes (MSSF / Buteo / PIM storage)
Date: Monday 7th March 2011 16:09:57 UTC (over 6 years ago)
Hi, given the events of the last few weeks, the MeeGo architects have, and still are, revisiting various parts of the MeeGo architecture. While I'd love to say that we have the whole situation clear, the reality is that there still is a very complex situation. In part because just not everything is clear yet around "who" and "what", and in part because various parts of the MeeGo OS architecture are very tightly coupled... it's not like MIkkado where you can pull out one stick at a time. Having said that, three items are currently clear enough to make a final decision on: 1) MSSF / MeeGo security framework 2) Buteo Sync 3) PIM storage (currently stored in the tracker database) Security ======= The security direction of MeeGo has been broken up into two different focuses: short-term and long-term.In the short term, we want to complete the development of key portions of the Mobile Simplified Security Framework that allow us to have complete solutions around the areas of Access Control, Integrity and Security Software Distribution.This will not entail *all* of the pieces that have previously been discussed in these areas, but instead will include a minimum subset of features that allow a coherent story across all key security areas. For MeeGo 1.2 specifically, this means that we're not planning on integrating the MSSF pieces that invasive or incomplete at this point, such as the "upstart" integration that was communicated on this list previously. In the long-term, we will re-evaluate the direction we are taking with MeeGo security with a new focus on *End-User Privacy*. While we do not intend to immediately remove the security enabling technologies we have been including in MeeGo, all security technologies will be re-examined with this new focus in mind.We will revisit technology choices made for MSSF (as well as non-MSSF components that have security implications) and make appropriate changes in these areas given this direction change. Buteo Sync ========== The Buteo Sync framework in MeeGo is currently very incomplete; various promised and needed components never materialized, and are unlikely to materialize in the future. On the Intel side, we've found that we ended up glueing SyncEvolution into Buteo on a regular basis to fulfill basic customer requirements (like sync-with-google-address-book). Because of this, and the available expertise, we have decided to start replacing Buteo with SyncEvolution. For MeeGo 1.2, it's not currently clear if the engineering work that this entails will be done in time, so 1.2 might still ship with Buteo. However, Buteo is removed as architectural component effective immediately to avoid creating an API/ABI promise for a component that we know is being replaced SyncEvolution is an existing mature open source project with a history of functionality and compatibility, and we're confident that the switch to this project will benefit Sync in MeeGo for years to come. PIM storage =========== The Address book, Calendar data and Email are currently stored in a tracker database, and accessed (officially) via a QtMobility API set. There are a range of issues with this implementation, starting with the complexity of adding privacy controls, the performance and scalability as well as the completeness for doing a proper syncml sync. Because of all these items and the available expertise, we have decided to start replacing PIM storage with the Evolution Data Server. This change will land together with the SyncEvolution change (due to the intimate relationship between the storage and sync of PIM data). This change should largely be invisible to applications since applications are supposed to access this data via the appropriate QtMobility APIs. But to avoid setting precedents, the lower level components will be removed from the architecture diagrams effective immediately. To be clear, this does not mean that "tracker" is completely removed; tracker is still being used (together with tumbler) for indexing media on the device. At this point we are seeing serious issues (performance/stability) with this solution, but the first attempt will be to fix the deficiencies rather than a replacement.