Hi there, Am Dienstag 15 November 2011, um 11:03:24 schrieb Patrick Ohly: > On Di, 2011-11-15 at 10:50 +0100, Christian Hilberg wrote: > [...] > > 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 :-)
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). > 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? Existing UIDs are (and must be) preserved. This is a requirement for Kolab client interop, since they all rely on the object's UID to reference it (especially regarding changes to the contents of the PIM object). In Kolab, there is no way to correctly reference an object other than using its UID. > If it does, do you throw a > E_BOOK_ERROR_CONTACT_ID_ALREADY_EXISTS when the existing UID is not > unique? Eeewww. :-) evolution-kolab presently sits on Evo/EDS 2.30.3 (which some like to call "just plain old" here =). No error message in that case. If the UID already exists, it gets rewritten. It was a tradeoff here - an existing Kolab object and its UID superseedes a new one. Imported objects are regarded as "new" (being assigned a new UID), should the UID they carry already exist in the given PIM folder. The original UID would do no good in the Kolab context if another object with that same UID already exists, since other groupware clients do have an idea about the object this UID refers to already. Trying to find out whether the imported object could actually be an update for an already existing one seemed too complex and out-of-scope for the initial evolution-kolab implementation. We're now porting to current Evo/EDS git master, but I would still keep the current implementation unchanged when it comes to how to interpret UIDs of imported objects. > > 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? In our current implementation, the UID will be unique to the Kolab server at hand. Since the Kolab server does not impose specific restrictions on the format of the UID, evolution-kolab could change the UID generation code (we currently use E-D-S infrastructure for this) to generate UUIDs. However, other Kolab clients are free to follow their very own scheme of UID formatting (they may well decide that UIDs unique for a given folder only are unique enough). I'm not clear whether the new Kolab format specification, which is in the makings right now, would enforce a UID to be globally unique. Older clients would not follow that scheme, so if you cannot rely on the UID of being globally unique, you do not gain anything. The Kolab philosophy is to offload almost everything to the clients for maximum scalability and minimum server load, accepting the fact that the server cannot really enforce anything. The Kolab server itself is, as I said, fully unaware of the PIM data. It stores all PIM objects as emails in IMAP folders. Hence, it will happily accept a client writing multiple PIM emails onto the server and into one PIM folder, all carrying the same UID. It is really all in the hands of the clients. If a new Kolab server will not enforce UIDs to be UUIDs (and it very certainly won't), then your gain is zero if you implement UUIDs in one client only. > > 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? This is a configuration option the user has. Kontact, as a reference client for Kolab, will ask you in all events of synchronization conflicts. In Evo/EDS 2.30, we did not have the infrastructure needed to query Kolab-specific user input from Evo, so the whole thing is non-interactive. For each PIM folder, you can configure the backends to use one of the following strategies: * use the "newer" PIM object (relies on timestamps - since these are set by the clients, not the Kolab server, it only works if the client's clocks are synced) * use the client's object (overwrites the one on the server) * use the server's object (discards the client's changes) * create a duplicate These strategies apply if an object is alredy known to at least 2 clients and is changed by both at the same time. If with "add<->add conflict" you mean that two clients are adding new PIM objects, and both mean the same (say, two people adding an object for the same event in some shared calendar folder), then there is no automatism to resolve this. The result is, that two PIM objects have been added. That's it. Any automatism to guess whether the two clients really really mean the same thing (and possibly merge the contents of the two objects into one) would be horribly complex and therefore would most probably fail to do The Right Thing exactly because of that. If people find they have both added a PIM object for the same thing into a shared folder, let them get into conversation, clarify things and remove one of the objects after achieving consensus. Kind regards, Christian -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Description: This is a digitally signed message part.
_______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers