On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote: > Hello! > > I'd like to write down some thoughts on vCard UID handling in EDS. > Andrew mentioned it on IRC, so I'm copying him. > > Let me define the terms to make the difference clear: > * UID: part of the contact properties. Ideally set once when a new > contact is created in such a way that it is globally unique > (same semantic as iCalendar 2.0 UID, not just unique inside the > current address book). Can and should be passed around and > preserved when exporting/importing contacts. > * local ID: local meta data about a contact, only relevant inside > an address book to look up contacts. > > The current situation is that EDS uses the vCard UID property for its > own local ID. When trying to create a new contact with UID already set, > that UID will be overwritten. > > This is problematic for interoperability (one cannot store a vCard > as-is) and syncing (which would benefit considerably from a > creator-assigned, fixed UID). > > This is partly an API and partly an implementation issue. The > libebook<->e_addressbook_factory D-Bus API just passes vCards, so a > vCard property has to be used for any local ID, and UID is the one that > is used. > > e_book_add_contact() doesn't have an explicit "local ID" retval. Clients > have to use e_contact_get_const(contact, E_CONTACT_UID) to retrieve the > assigned local ID. Other APIs avoid that. For example, > e_book_add_contact_async() + EBookIdAsyncCallback return the ID > out-of-band. > > The more recent EBookClient API always uses separate ID retvals. > However, in contrast to the EBook API it specifies that these are the > UID of the created contact and not some kind of local ID. The older API > left that undefined and just talked of "id". > > I see several ways forward: > 1. Accept that a contact ID as used in the EBook API is the vCard > UID and make it possible to set that UID when creating a new > contact. That implies for adding a contact: > * remove the code which overwrites the UID > * add check for existence of the UID in the address book > and a corresponding error code if it does > 2. Use the local ID in the EBook API and support storing the vCard > UID separately. Support lookup of a contact by UID. > > The advantage of the second approach is that it is potentially more > efficient. I myself took advantage of that in the EDS<->QtContacts > bridge code. But it never was a full solution (depended on 32 bit local > IDs, which is okay for the file backend, but not all of them, and > required patching EDS). > > The disadvantage of the second approach is an API change and/or > extension. It has some potential advantages, but as the EDS<->QtContacts > bridge is not used anymore, there is little incentive to do the extra > work right away. > > So I suggest to pursue the first approach instead. I think it is > possible for the file backend. > > Is it also possible for other backends? Or are some unable to store the > UID and look up contacts (efficiently) by it? In that case we will have > to relax the semantic of the API and accept that some backends still use > their own local ID. "Supports UID" should be defined as a capability of > the backend so that clients can take it into account.
Just went through the thread and had a small discussion with mcrha. My preference goes with the first approach along with having the static capability. - Chenthill. _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers