Re: [Evolution-hackers] UID in vCard
Hi Patrick, Am Mittwoch 16 November 2011, um 15:55:54 schrieb Patrick Ohly: Hello! [...] On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote: 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). With client, I meant an EDS client here (= the application using libebook). That there is a Kolab client and server involved is of course important for you, but not so much for a user of the abstract libebook API ;-) 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. The E-D-S client (like Evo) would then see UUIDs and be happy with it. Now imagine someone in Evo exports a PIM object which originates from a Kolab server. Evo would write the E-D-S UUID into that PIM object. Now, by some nice round-trip, this exported PIM object would reach a user of the Kolab server it originated from. By importing the object into the Kolab server, we would then generate a dupe, since the Kolab UID for a PIM object *is* the iCal/vCard UID of an object stored. While this would have the potential of being a self-healing process over time (a PIM object duplication is detected, the one with the UID which is not UUID is deleted), it would take a very long time for the healing to be completed, and only then you could really rely on the assents a UUID makes. To give you a hint about the numbers we're talking about, it is not uncommon for a Kolab deployment to host thousands of contacts and incident types, potentially shared among hundreds of users with various clients. Implementing UUIDs in our backend, as I said, is not an issue. The issue is more like what to you gain if you cannot rely on the UID you see to be really globally unique. In Kolab context (that's why I'm talking about it here), a mapping between Kolab-UID and E-D-S-UUID would not help you in PIM data exchange and sync interplay. 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. 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. For the evolution-kolab backend, only those UIDs are rewritten which do already exist on the Kolab server. UUIDs would, as a matter of fact, be helpful here. There is *some* risk, however, that by chance you generate a UUID for a PIM object, and may find that even this one exists on the server, because out of full randomness, a UUID-unaware Kolab client hase decided that exactly *this* would be the UID string it would want to use today. Granted, this is a corner case and it should hit so very seldom that manual intervention would be acceptable. My point is, that you might be very well able to make good use of UUIDs if you implemented a fully new system, which would enforce all clients to be using UUIDs and all servers dealing with objects checking that the UID
Re: [Evolution-hackers] UID in vCard
On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote: Am Mittwoch 16 November 2011, um 15:55:54 schrieb Patrick Ohly: Hello! [...] On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote: 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). With client, I meant an EDS client here (= the application using libebook). That there is a Kolab client and server involved is of course important for you, but not so much for a user of the abstract libebook API ;-) 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. 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. 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. -- 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
Re: [Evolution-hackers] UID in vCard
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 *mp* 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 UUID. 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/ 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 Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote: Hello! I'd like to write down some thoughts on vCard UID handling in EDS. Andrew mentioned it on IRC, so I'm copying him. Let me define the terms to make the difference clear: * UID: part of the contact properties. Ideally set once when a new contact is created in such a way that it is globally unique (same semantic as iCalendar 2.0 UID, not just unique inside the current address book). Can and should be passed around and preserved when exporting/importing contacts. * local ID: local meta data about a contact, only relevant inside an address book to look up contacts. The current situation is that EDS uses the vCard UID property for its own local ID. When trying to create a new contact with UID already set, that UID will be overwritten. This is problematic for interoperability (one cannot store a vCard as-is) and syncing (which would benefit considerably from a creator-assigned, fixed UID). This is partly an API and partly an implementation issue. The libebook-e_addressbook_factory D-Bus API just passes vCards, so a vCard property has to be used for any local ID, and UID is the one that is used. e_book_add_contact() doesn't have an explicit local ID retval. Clients have to use e_contact_get_const(contact, E_CONTACT_UID) to retrieve the assigned local ID. Other APIs avoid that. For example, e_book_add_contact_async() + EBookIdAsyncCallback return the ID out-of-band. The more recent EBookClient API always uses separate ID retvals. However, in contrast to the EBook API it specifies that these are the UID of the created contact and not some kind of local ID. The older API left that undefined and just talked of id. I see several ways forward: 1. Accept that a contact ID as used in the EBook API is the vCard UID and make it possible to set that UID when creating a new contact. That implies for adding a contact: * remove the code which overwrites the UID * add check for existence of the UID in the address book and a corresponding error code if it does 2. Use the local ID in the EBook API and support storing the vCard UID separately. Support lookup of a contact by UID. The advantage of the second approach is that it is potentially more efficient. I myself took advantage of that in the EDS-QtContacts bridge code. But it never was a full solution (depended on 32 bit local IDs, which is okay for the file backend, but not all of them, and required patching EDS). The disadvantage of the second approach is an API change and/or extension. It has some potential advantages, but as the EDS-QtContacts bridge is not used anymore, there is little incentive to do the extra work right away. 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. Just went through the thread and had a small discussion with mcrha. My preference goes with the first approach along with having the static capability. - 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
Hello! Before I reply to Christian, let me elaborate a bit more on why overwriting the UID is bad for syncing. I thought it was obvious, but probably not ;-} What I have in mind is a system where contact data moves freely and ad-hoc between peers, without being forced to go through a central server, stick to a fixed topology or use a specific database technology. This cannot be done with today's technology because avoiding duplicates becomes unreliable. CouchDB comes close, but is a closed system. You also cannot create two independent CouchDB instances and then merge them (at least that is my understanding - I might be wrong on that particular aspect). A creator-assigned global UID would be the right way of solving this. Storages or systems which do create and preserve such a UID cannot participate in that system. I'd like to make sure that the EDS file backend can be part of it, even if it is just for experiments. For more details, see the TODOs on ad-hoc synchronization in http://syncevolution.org/blogs/pohly/2011/state-union-version-12 On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote: 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). With client, I meant an EDS client here (= the application using libebook). That there is a Kolab client and server involved is of course important for you, but not so much for a user of the abstract libebook API ;-) 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. 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. Consider sending around vCard with globally unique UID. A user might import that vCard once into Kolab using Kolab client A. Then when he tries again with Kolab client B, the client can warn him reliably that this particular contact was already imported. 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
Re: [Evolution-hackers] UID in vCard
On mié, 2011-11-16 at 15:55 +0100, Patrick Ohly wrote: CouchDB comes close, but is a closed system. You also cannot create two independent CouchDB instances and then merge them (at least that is my understanding - I might be wrong on that particular aspect). not sure what you mean, but if I've understood correctly, you are wrong :-) You can create 2 couchdb instances and then sync them. cheers ___ 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 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
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
Re: [Evolution-hackers] UID in vCard
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. For example with Google calendar, which is served by CalDAV backend, the backend fetches newly added event from the server only to present UI with real object from the server, because the server can modify the event on its own when creating it (it adds default alarms, if set in Google's calendar preferences on the Web). Just my quick ideas on the issue, if I got it right. Bye, Milan ___ 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 Mo, 2011-11-14 at 11:22 +0100, Milan Crha wrote: 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 I wouldn't use the term UID at all for this local (or backend) ID. UID has a specific meaning for both iCalendar 2.0 (where it is well-defined) and vCard (where it is less well-defined). Introducing yet another flavor of UID just leads to confusion, in particular when the same contact has both the original vCard UID and a local backend 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. So we do need the concept of local IDs which are not the same as the creator-assigned UID. 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? And what does that mean for the file backend? I still think it would be good if the file backend supported creator-assigned UIDs. That other backends can't do that doesn't mean that file backend is not allowed to do it, right? For example with Google calendar, which is served by CalDAV backend, the backend fetches newly added event from the server only to present UI with real object from the server, because the server can modify the event on its own when creating it (it adds default alarms, if set in Google's calendar preferences on the Web). Are you saying that Google Calendar EDS does *not* report the original iCalendar 2.0 UID? -- 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
Re: [Evolution-hackers] UID in vCard
On Mon, 2011-11-14 at 21:06 +0100, Patrick Ohly wrote: On Mo, 2011-11-14 at 11:22 +0100, Milan Crha wrote: 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. I wouldn't call it local UID, it's rather backend's UID I wouldn't use the term UID at all for this local (or backend) ID. UID has a specific meaning for both iCalendar 2.0 (where it is well-defined) and vCard (where it is less well-defined). Introducing yet another flavor of UID just leads to confusion, in particular when the same contact has both the original vCard UID and a local backend UID. Yep, that would be a LUID (Local UID) ___ 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 Mon, 2011-11-14 at 21:06 +0100, Patrick Ohly wrote: On Mo, 2011-11-14 at 11:22 +0100, Milan Crha wrote: 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. I wouldn't call it local UID, it's rather backend's UID I wouldn't use the term UID at all for this local (or backend) ID. UID has a specific meaning for both iCalendar 2.0 (where it is well-defined) and vCard (where it is less well-defined). Introducing yet another flavor of UID just leads to confusion, in particular when the same contact has both the original vCard UID and a local backend UID. Yep, that would be a LUID (Local UID) ___ 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 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. And what does that mean for the file backend? I still think it would be good if the file backend supported creator-assigned UIDs. That other backends can't do that doesn't mean that file backend is not allowed to do it, right? Sure, file backend can preserve already set UID. For example with Google calendar, which is served by CalDAV backend, the backend fetches newly added event from the server only to present UI with real object from the server, because the server can modify the event on its own when creating it (it adds default alarms, if set in Google's calendar preferences on the Web). Are you saying that Google Calendar EDS does *not* report the original iCalendar 2.0 UID? Nope, I'm not saying that. Note the Google calendar in EDS means CalDAV. The CalDAV backend doesn't change UID at all, it sets it only if the component to be created doesn't contain it. And it also claims an error when you try to create an object with UID which already exists. It's the desired behavior you are looking for with the file backend, if I got your request right. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
