Am Montag, den 04.04.2011, 09:48 +0200 schrieb Patrick Ohly: > On Fr, 2011-04-01 at 12:26 +0100, Mathias Hasselmann wrote: > > 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. > > I was wondering about the UID part and came to the same conclusion as > you: passing the UID inline doesn't look right. Another conceptual > problem with it is that EDS cannot store a true, creator-assigned UID > (think iCalendar 2.0 UID property). EDS will always wipe out that > "real" (U)UID and replace it with a local ID. > > vCard doesn't mandate such a globally unique ID, but for MeeGo<->MeeGo > sync we could take advantage of some extra knowledge about our peer - if > we had a real UID, which currently we don't (in EDS - not sure about > QtContacts-Tracker). > > > 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. > > I had considered that, but I guess the actual benefit would depend a lot > on the access patterns by the apps: if reporting the UID is always > followed by an immediate data access by the app, then it might be better > to leave the EDS [D-Bus] API as it is, cache the transmitted data in > QtContacts-EDS and then report it directly when the app asks. > > > > 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. > > This is for QtContacts change notifications. The way EDS works now, I > have to set up a view that matches all contacts. When the view is > created, EDS will send all data followed by a "view-complete" signal. > For QtContacts, only changes *after* the "view-complete" are relevant. > All the data would just be dropped (or cached as suggested above, but > caching the whole address book won't work well). > > The line above is misleading: it should say "suppress sending initial > data dump". All following changes should be handled normally. > > > > > 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. > > So ebook is covered, or at least doesn't regress. With libical it might > be a bit harder. icalcomponent_new_from_string() currently returns NULL > if the item cannot be parsed; silently returning an icalcomponent with > unparsed data would disable the existing error checking in apps. > > > > > more efficient access to meta data for change tracking + atomic > > > > updates > > > > Sounds familiar: e_book_get_changes() > > SyncEvolution used that initially and moved away from it because it was > too limited. For example, it is impossible to distinguish or even detect > changes made by some other app while making changes yourself.
AFAIR we had an solution for that in F-EDS, but have some trouble to remember right now. Guess I'd have to compare upstream and Fremantle source code. Some one mates from F-EDS times follow this thread and remember the details? > > > > 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? > > In sync, the photo is already detached. I wanted to have some way of > storing it in the right location without having to encode it inline > first. Perhaps it isn't important enough to make the API as complex as > it (obviously) becomes. We definitely can focus on "detach inline data > automatically" first. > > > EContactPhoto permits both detached and inline > > photos. libebook only would have to take care, of generally detaching > > inline photos. > > Minor caveat here: some EDS backends need the photo inline, like the > various Groupware backends. So libebook shouldn't do it unconditionally. For libosso-abook we solved the problem like that: http://maemo.org/api_refs/5.0/5.0-final/libosso-abook/OssoABookContact.html#osso-abook-contact-to-string char* osso_abook_contact_to_string (OssoABookContact *contact, EVCardFormat format, gboolean inline_avatar); Other useful API: http://maemo.org/api_refs/5.0/5.0-final/libosso-abook/OssoABookContact.html#osso-abook-contact-write-to-file void osso_abook_contact_write_to_file (OssoABookContact *contact, EVCardFormat format, gboolean inline_avatar, gboolean strict_filename, GFile *parent_file, OssoABookContactWriteToFileCb callback , gpointer user_data); Is there someone at Intel who could convince Nokia to contribute libosso-abook to Meego? So much useful code which would should not have to be written again. > > While scratching that topic: You also want to have a smart charset > > detected for vCards not passing UTF-8 validation. > > Our first line of defense in most cases will be QVersit, not the EDS > parser. Does it handle that already? >From quickly reading the QtVersit code it seems there is quite some room for improvement still. Ciao, Mathias -- Mathias Hasselmann <[email protected]> http://openismus.com/ _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
