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. No, what I would prefer are improvements for reading meta data (think HTTP PROPFIND and eTags), and then let clients of EDS implement the necessary logic that fits their use cases. > > > 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. > > > 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. Agreed. > 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? -- 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
