Re: [Evolution-hackers] UID in vCard

[Patrick Ohly <patrick ohly gmx de>]

On Di, 2011-11-15 at 10:50 +0100, Christian Hilberg wrote:
> Hi everyone,
> 
> Am Montag 14 November 2011, um 11:22:57 schrieb Milan Crha:
> > On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote:
> > > 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.
> > 
> > 	Hi,
> > I wouldn't call it "local UID", it's rather "backend's UID" and mostly
> > not, this is not doable for groupware backends which are using
> > server-supplied unique identifiers for contacts/calendars, like message
> > IDs in evolution-mapi, which talks to Exchange servers. It's easier, and
> > makes sense, to use server-side IDs, which are meant to be unique.
> > It's also a reason, from my point of view, why
> > e_data_book_respond_create_contacts() passes UIDs of newly created
> > objects back to the client.
> > [...]
> 
> Just adding a few bits on how the situation is for the Kolab groupware server.
> 
> The evolution-kolab backend cannot ask the Kolab server for a UID (since there
> is no API for that) nor does the server enforce certain UIDs on a PIM object (but,
> of course, that there be one). The only requirement is that the PIM object's UID
> be unique in a given PIM folder. If the UID is globally unique, all the better.

That's the same situation as with the file backend then: a client could
decide to set a UID in the vCard before creating the contact, and the
Kolab backend+server would use that UID instead of creating their own.
Good :-)

How does the backend work at the moment? Does it always overwrite an
existing UID like the file backend does or does it already work as I
proposed? If it does, do you throw a
E_BOOK_ERROR_CONTACT_ID_ALREADY_EXISTS when the existing UID is not
unique?

> PIM objects already residing on the Kolab server do carry a UID, created by the
> client which created the object (evolution-kolab, Kontact, Horde, Outlook with
> a Kolab connector, Thunderbird via Lightning/SyncKolab, ...).

Do you attempt to make the UID globally unique, for example by using a
UUID?

> When it comes to importing a PIM object, it is not possible to retain its
> UID in the cases where the same UID exists on the server already for another PIM
> object (unlikely, but possible, since Kolab object UIDs are not required to be
> globally unique). As long as we're in offline mode, we may at first succeed retaining
> the object's UID, but when going online any syncing with the server, find that
> a new UID must be set on the object.

What happens during syncing? Do you resolve the add<->add conflict by
duplicating the item, merging them or discarding one copy?


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