> From: Patrick Ohly, on 21 March, 2011 16:37 > 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.
This will break libcommhistory. What do you suggest? As explained earlier, one technical requirement is that contacts and IM/callhistory data should be in the same database. Options: 1. Support for IM and call history in EDS 2. Duplicate/sync to tracker of contact fields needed for building conversation history and call history 3. Shared memory contacts model with own indexing across domains. 4. Catastrophic messaging performance drop (10-100 times if I remember right from early tracker bugs for missing index). See the queries here: http://gitorious.net/commhistory/libcommhistory/trees/master/sparql Where else do you want to see performance improvements by moving Contacts to EDS, if not in the most performance critical areas (e.g. IM conversational view)? This use case shall be solved by the ones who made the "architecture decision" ruining it. Which one should it be, and who will do the work? Regards, Zoltan > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
