[Evolution-hackers] [Fwd: [MeeGo-dev] migration (back) to EDS]

[Patrick Ohly <patrick ohly gmx de>]

Hello Evo hackers!

If you see some increased interest in EDS soon, then it might be because
MeeGo is currently investigating how to use EDS as the main PIM and
email system again.

Attached a rough outline of the current ideas. My expectation is that we
will start sharing more thoughts and questions here as we proceed.

Note that this work probably has to be delivered to MeeGo as part of an
Evolution 2.32 based solution, because I don't see us moving to 3.0 soon
enough.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/

--- Begin Message ---

• From: Patrick Ohly <patrick ohly intel com>
• To: MeeGo-dev <meego-dev meego com>
• Subject: [MeeGo-dev] migration (back) to EDS
• Date: Mon, 21 Mar 2011 14:36:31 +0000

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
MeeGo-dev meego com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

--- End Message ---