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 Ohly gmx de
http://www.estamos.de/




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]