Hi, Am Freitag 18 November 2011, um 16:53:38 schrieb Patrick Ohly: > On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote: > [...] > > 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. Writing UIDs as UUIDs only would definitely be a good thing to start with. > > > 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. From evolution-kolab's point of view, it would be simple to return a "*meeeep* UID already exists, try again"-error to E-D-S in that case, provided the E-D-S API for that existed. > 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. Again, in Kolab context, the user of the calendar lib or addressbook lib would still get a vague indication only. The race condition could still occur, since there is (a) no transactional system provided by the Kolab server for PIM object creation and (b) any Kolab client is required to fully work in offline mode. While offline, we can check in our local cache whether a UID collision was about to occur and return the corresponding error message to E-D-S. Assume there was no UID collision in offline mode, it may well show up when we're going online again some time later. Imagine, while in offline mode, the PIM object in question has been exported already, carrying the believed-to-be-unique ID, while the object in the offline cache faces a UID collision when being spooled onto the server. Even if we fail to spool that object onto the server since we detected an add<->add collision there, and ask the user for some interaction, we may already have the exported- in-offline-mode-object circulate elsewhere, e.g. by sending it via email, playing funny tricks on us when we try to rely on its "U"UID. As you can see, we can play this game back and forth. AFAICS, the following may be a good start: * have E-D-S generate good UUIDs * give the backends the chance to report if a UUID already exists (if the error does not pop up instantly, it does not mean everything is well, but *if* it does, certainly E-D-S can try again and generate another UID, and notify the user) * encourage all backend implementors not to overwrite existing UIDs, if at all possible Just 2 cents, Christian -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.