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