> From: Patrick Ohly [mailto:[email protected]] Sent on 21 March, 2011 > 21:55
> > This will break libcommhistory. > I'm aware of that, and I don't claim that there is an answer. There is > a task open for those who need libcommhistory Those who need it are messaging-ui, call-history, commhistory-daemon (handling the storage), qt-mobility, qt webruntime, at-phonebook, msgsync. I assumed the dependencies have been checked before announcing the change. Where is this task open and to whom? Is there a bug? > (or something like it) What are the other options instead of libcommhistory? >to look into this problem and comment on the current proposals. I expect there is an answer already now, because this was called an architecture decision, and as such, it must have addressed all the basic use cases and consequences _before_ it was made, right? I cannot believe these important dependencies were not considered when the decision was made to move back to EDS... BTW who made the decision (meeting minutes please?), and where is it documented? I have asked it earlier too: what is the governance model of MeeGo now? So far no change was announced, and since moving Contacts back to EDS was an authoritative and arbitrary, rather than technically justified "architecture decision", it should be considered *void* until it's done properly. I am not against it per se, just against the non-professional way it was made, and against ignoring all facts, measurements and dependencies listed on this mailing list, that make clear this was a bad (incomplete) decision, at least concerning Contacts. Making Sync somewhat simpler is not enough reason to break half the system (see the list below). CC'ing Arjan, Sakari, and Mikko. Option 2 from below would be the cheapest, fastest and least pain path but it's duplicating contacts to tracker. Option 3 would be optimal but difficult, option 1 could also work. Choose one, or suggest something else. Please finish the job you started :). Regards, Zoltan > -----Original Message----- > From: Zoltan Kis, on 21 March, 2011 19:45 > To: [email protected]; [email protected] > Subject: Re: [MeeGo-dev] migration (back) to EDS > > > 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 > > [email protected] > > http://lists.meego.com/listinfo/meego-dev > > http://wi
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
