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
