Hello!
I promised to share some more information about what we intend to do
about using EDS in MeeGo. Please let's focus on the technical
challenges. There are some exploratory steps at this time, but no
specific schedule. Components which are currently in MeeGo are still
needed, so please continue to support them with bug fixes.
In a nutshell, the goal is to keep QtContacts, QMF and KCalCore as the
main APIs used by applications and the higher-level QtMobility APIs. If
we can achieve that, very little will have to be done in applications
once we change the core components.
Calendar Storage
* use upstream KDE version of KCalCore
* write storage which uses libecal/EDS
* add content protection to EDS
* remove unnecessary parsing of iCalendar in libecal (not needed
by storage and sync)
* improve reading of meta data (can speed up sync, see "concurrent
modifications of items in GUI and EDS database" on the
evo-hackers list from back in 2009)
Contact Storage
* write a QtContacts manager which uses libebook/EDS, similar to
QtMobility manager for Harmattan, but with some crucial
differences:
* avoid ID mapping because it requires reading all
contacts at startup; must change EDS to use 32 bit
integers as local IDs for that (patch ready)
* convert between QtContacts and vCard using QtVersit,
with EDS specific properties and including custom
properties for QtContactDetails which have no other
mapping to vCard (same approach as in SyncEvolution
QtContacts backend); this avoids lots of hand-written
mapping code which depends on the (necessarily
incomplete) EContact API
* no support for relationships
* no support for change tracking, that logic needs to be in higher
layers
* support for groups open - special contact as done by Evolution
itself?
* "self contact" also under debate
* change notifications via ebook view
* add content protection to EDS
* store PHOTO data outside of EDS
* remove unnecessary parsing of vCard in libebook (not needed by
plugin and sync)
* other performance and feature improvements as needed (for
example, reading meta data as for calendar above)
* correlation with other data sources (online status,
communication history) handled by systems above EDS (libfolks?)
Obviously we are going down a similar route as Nokia did with Maemo
Fremantle. One difference is that all work should be done and reviewed
upstream first, and that the (admittedly rather ugly) EDS APIs for
manipulating contacts and events in apps would be replaced with more
convenient C++ APIs. C code still has the option of using the
traditional EDS APIs.
Mail Storage and Transports
* write simplistic server which runs Camel
* replace QMF client library with one which accesses that server;
source code compatibility of just the functionality needed by
the Tablet mail app would be a good first step
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
