Re: [Evolution-hackers] UID in vCard
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 evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - Nov 16 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates http://live.gnome.org/Evolution/CommunityMeet - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] UID in vCard
Am Dienstag 15 November 2011, um 15:01:54 schrieb Christian Hilberg: Am Dienstag 15 November 2011, um 11:03:24 schrieb Patrick Ohly: [...] 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 Adding some more bits: The evolution-kolab user manual has some more info on the current behaviour of the plugin in 3.4.2 Conflict solving strategies, see [1]. Kind regards, Christian [1] http://sourceforge.net/projects/evolution-kolab/files/evolution-kolab_user-manual_v1.3.pdf/download -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] UID in vCard
On Tue, 2011-11-15 at 08:41 +0100, Milan Crha wrote: On Mon, 2011-11-14 at 21:06 +0100, Patrick Ohly wrote: What about a CardDAV server? It has server-supplied IDs (the path to the resource) and a UID as part of the vCard stored there? How is that handled at the moment? Hi, there is no exact support for CardDAV as such, the closest is the WebDAV backend, and it generates its own UID too, and it also can download just added contact from the server. It use eTag value as a revision value. hi Milan, The WebDAV backend for the addressbook works fine against a CardDAV server. Unlike CalDAV where there are substantial differences between WebDAV calendars and CalDAV, WebDAV for addressbooks is a compatible subset of CardDAV. Cheers, Andrew. -- andrew (AT) morphoss (DOT) com+64(272)DEBIAN Does the name Pavlov ring a bell? signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
