Re: [Evolution-hackers] UID in vCard

[Chenthill <pchenthill gmail com>]

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.