On Di, 2011-11-15 at 10:50 +0100, Christian Hilberg wrote: > 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.
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 :-) 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? If it does, do you throw a E_BOOK_ERROR_CONTACT_ID_ALREADY_EXISTS when the existing UID is not unique? > 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? > 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? -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers