Re: [Evolution-hackers] UID in vCard

[Patrick Ohly <patrick ohly gmx de>]

On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote:
> Am Mittwoch 16 November 2011, um 15:55:54 schrieb Patrick Ohly:
> > Hello!
> > [...]
> > On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote:
> > > If a new UID is to be created, it is the responsibility of the Kolab client to
> > > assign one. The Kolab server itself is unaware to object UIDs and will not touch
> > > them (no read/write/anything).
> > With "client", I meant an EDS client here (= the application using
> > libebook). That there is a Kolab client and server involved is of course
> > important for you, but not so much for a user of the abstract libebook
> > API ;-)
> 
> While the E-D-S client (like Evo) might not be interested whether it is
> a Kolab backend being used, there is still one thing you may wish to consider here.
> We could of course map between Kolab PIM object UIDs and E-D-S UUIDs in our
> backend.

That should never be necessary. As you said, having such two different
ids doesn't buy the user much. Only a radical step away from "do what
you want with UID" to "UID must be UUID and preserved" will - not
realistic anytime soon, but at least a proof-of-concept would be nice.

> > That is the whole point of this mail thread: a vCard UID may have a
> > meaning outside of the storage in which it currently exists. EDS cannot
> > know whether that is the case. Currently it assumes that the UID has no
> > meaning and throws it away when adding contacts.
> 
> Not globally true. The file backend may do so, but it is the backend implementation
> deciding whether re-writing a UID or not. E-D-S cannot decide that, since it does
> not know what a given backend is dealing with.

What I meant is the Evolution/EDS API expectation that adding a contact
will never fail because of a UID conflict. Whether the backend
implements that by always overwriting the UID (as the file backend does)
or by keep it when possible and overwriting otherwise (as in the Kolab
backend) is indeed a backend implementation detail.

But it has the same effect: a libebook user cannot reliably detect an
add<->add UID conflict. It can check for a contact with the UID first
(by assuming that ID in the libebook API == UID in vCard), but then
there's still a race condition between that check and creating that
contact.

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