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. 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, ...). An existing UID of a PIM object must be retained, of course. Every Kolab client will follow its own approach creating UIDs. Possible clashes need to be handled by the clients. When creating a new PIM object, the Kolab client needs to create a UID for it. Kolab objects are referenced by folder/UID in evolution-kolab. While mapping between a "E-D-S backend UID" and the "Kolab UID" would be certainly possible, it would require another level of lookups, which has the potential for being inefficient. 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. No final statement here, just a dump of what came to mind. :-) So here's my 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.