Hi, As a QMF developer I would like to avoid further unnecessary divergence in the QMF API, I'm more than happy to work with you and others at MeeGo towards that goal. Please keep in touch and let me know about any changes you need to make to the API.
Regarding the decision to not use the QMF implementation personally I do disagree with this, and I'm willing to give technical arguments in favor of QMF if there is any interest in hearing them. Kind regards, Don Sanders - Messaging Lead Qt Development Frameworks, Nokia - http://qt.nokia.com/ On 2011-03-22T00:36:31, ext Patrick Ohly wrote: > 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 > _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
