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.
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
