Re: [Evolution-hackers] UID in vCard

[Patrick Ohly <patrick ohly gmx de>]

On Fri, 2011-11-18 at 17:27 +0100, Christian Hilberg wrote:
> Am Freitag 18 November 2011, um 16:53:38 schrieb Patrick Ohly:
> > On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote:
> > > > That is the whole point of this mail thread: a vCard UID may have a
> > > > meaning outside of the storage in which it currently exists. EDS cannot
> > > > know whether that is the case. Currently it assumes that the UID has no
> > > > meaning and throws it away when adding contacts.
> > > 
> > > Not globally true. The file backend may do so, but it is the backend implementation
> > > deciding whether re-writing a UID or not. E-D-S cannot decide that, since it does
> > > not know what a given backend is dealing with.
> > 
> > What I meant is the Evolution/EDS API expectation that adding a contact
> > will never fail because of a UID conflict. Whether the backend
> > implements that by always overwriting the UID (as the file backend does)
> > or by keep it when possible and overwriting otherwise (as in the Kolab
> > backend) is indeed a backend implementation detail.
> 
> From evolution-kolab's point of view, it would be simple to return a
> "*meeeep* UID already exists, try again"-error to E-D-S in that case,
> provided the E-D-S API for that existed.

As Matthew said, the Evolution UI itself is probably not able to handle
such an error at the moment. So at the end of the day, it might be the
client which has to tell EDS+backend and/or libebook which behavior it
wants: preserve UID at all costs (including throwing errors) or emulate
the current semantic (don't throw errors, overwrite UID if necessary).

> > But it has the same effect: a libebook user cannot reliably detect an
> > add<->add UID conflict. It can check for a contact with the UID first
> > (by assuming that ID in the libebook API == UID in vCard), but then
> > there's still a race condition between that check and creating that
> > contact.
> 
> Again, in Kolab context, the user of the calendar lib or addressbook lib
> would still get a vague indication only. The race condition could still
> occur, since there is (a) no transactional system provided by the Kolab server
> for PIM object creation and (b) any Kolab client is required to fully work
> in offline mode.

This leads to another pet peeve of mine: all backends should be able to
work in read/write offline mode. This implies syncing between local and
remote data when going online, which should be provided as a core
feature of EDS instead of being replicated in every single backend.
Akonadi provides such a feature.

I have some ideas how SyncEvolution could be used for that inside
EDS/Evolution, but that's a topic for another day and mail thread...

> AFAICS, the following may be a good start:
> * have E-D-S generate good UUIDs
> * give the backends the chance to report if a UUID already exists
>   (if the error does not pop up instantly, it does not mean everything
>   is well, but *if* it does, certainly E-D-S can try again and generate
>   another UID, and notify the user)
> * encourage all backend implementors not to overwrite existing UIDs,
>   if at all possible

Agreed.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/