[Evolution-hackers] UID in vCard

[Patrick Ohly <patrick ohly gmx de>]

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.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/