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 -- [email protected] http://www.estamos.de/ _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
