On Mon, 2011-11-14 at 21:06 +0100, Patrick Ohly wrote:
> 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?

        Hi,
there is no exact support for CardDAV as such, the closest is the WebDAV
backend, and it generates its own UID too, and it also can download just
added contact from the server. It use eTag value as a revision value.

> 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?

Sure, file backend can preserve already set UID.

> > 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?

Nope, I'm not saying that. Note the Google calendar in EDS means CalDAV.
The CalDAV backend doesn't change UID at all, it sets it only if the
component to be created doesn't contain it. And it also claims an error
when you try to create an object with UID which already exists. It's the
desired behavior you are looking for with the file backend, if I got
your request right.
        Bye,
        Milan

_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Reply via email to