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.o...@gmx.de http://www.estamos.de/ _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers