Now after criticizing the comparison page something constructive information for the EDS plan.
First of all it should be noted, that the QtContacts API was designed after careful review of the libebook API and considering experience gained during Fremantle. Therefore QtContacts can be seen as some kind of descendant of EDS, trying to avoid some of its faults. Am Dienstag, den 29.03.2011, 16:35 +0200 schrieb Patrick Ohly: > http://wiki.meego.com/Architecture/planning/evolution-data-server/QtContacts_storage_plugin > > change notifications via ebook view: created when opened, initial > > data dump ignored (performance problem!), report all following > > changes This problem was successfully worked around for Fremantle by adding lazy vCard parsing to its EDS version: EDS transfers changed contacts as vCard string and then libebook spends a lot of time in parsing it, just to deliver a EContact from which maybe only the UID is read. We changed the signal to deliver both the UID and the vCard string for each contact and patched EVCard (base class of EContact) to only store a copy of both. The vCard string itself only would be parsed when vCard attributes are read for the first time. After parsing the now obsolete vCard string is discarded. This gave us a really nice performance boost. From something likes 14 seconds to process all notifications, down to some hundred milliseconds. This trick works because usually only very few contacts are shown at a time and therefore only very few vCards must be parsed initially. Another trick would be, to introduce a new signal that only reports UIDs and let clients later fetch the contacts they are interested in, like QtContacts does. > http://wiki.meego.com/Architecture/planning/evolution-data-server/eds-improvements > > extend EDS query language with a flag that suppresses existing data Can you explain this idea a bit? To me it seems quite hard to do, since EDS only stores vCard strings. It has now idea about their meaning. > > optional parsing of data in client Nice to see lazy vCard parsing considered already, but let me comment on that section a bit. > > 1. If delayed parsing fails, how can error be reported. 1. EDS only stores and reports valid vCard strings. This is guaranteed by the contact saving API only accepting EContact instances, which then are converted to valid vCard via e_vcard_to_string(). 2. Upstream EDS also doesn't do any error reporting right now. It only spits warnings to the console and e_vcard_get_attributes() will return a quite terse list. Same API works with lazy parsing. > > more efficient access to meta data for change tracking + atomic > > updates Sounds familiar: e_book_get_changes() > > contacts: store PHOTO data as plain files > > > > For apps which want to create the photo file directly: > > * Apps get a file descriptor and the path from a new libebook API. > > * They own the file until the EDS server acknowledges the > > successful storing of a contact with a matching > > PHOTO;VALUE=uri:file property. If that fails, the app must remove > > the file. Why such complicated API? EContactPhoto permits both detached and inline photos. libebook only would have to take care, of generally detaching inline photos. This writing should be done using async API to avoid UI blocking. Another approach might be something like e_vcard_detach_photo(). This TBD function would explicitly detaches inline photos, any maybe directly return the generated filename. > > Trust TYPE=JPEG/PNG/... or look into file content to determine type? First rule of vCard survival: Never trust any vCard. Those you get are malformed crap, lying about their charsets and image file formats. Content inspection is needed to figure out the image type. While scratching that topic: You also want to have a smart charset detected for vCards not passing UTF-8 validation. They will be in any random encoding ever invented. For Fremantle we have integrated Mozilla's charset detector [1][2]. As I learned just yesterday it seems MeegoTouch also features MCharsetDetector. Maybe that code is even more useful - have not tested it yet. Since libosso-abook already has most of the code it might be worth to take this last chance and ask Nokia for source code of libosso-abook. It's of little value for Nokia now, but would be a great contribution for future development of Meego on its way back to EDS. We could reopen the related Maemo.org bug[3] or maybe someone has ideas for even more efficient channels. Ciao, Mathias [1] https://maemo.gitorious.org/eds-fremantle/eds-fremantle/blobs/master/addressbook/libebook-dbus/e-uchardet.cpp [2] https://maemo.gitorious.org/eds-fremantle/eds-fremantle/trees/master/libuchardet [3] https://bugs.maemo.org/show_bug.cgi?id=5549 -- Mathias Hasselmann <math...@openismus.com> http://openismus.com/ _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
