Re: [Evolution-hackers] UID in vCard

[Milan Crha <mcrha redhat com>]

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