Re: [VCARDDAV] [caldav] new webdav sync draft

On Mon, 2009-12-07 at 21:43 +0100, Helge Hess wrote:
> On 07.12.2009, at 16:55, Cyrus Daboo wrote:
> > Just to clarify - right now the spec says that a resource
> > that is deleted and re-created is reported as "new" if a
> > sync-token prior to the deletion is given in the REPORT.
> 
> Ah, OK. I would have expected a "deleted" and a "new" entry in such a
> case.

Yes, and in fact I revisited my code for this situation after reading
Cyrus' note and discovered that I had implemented that particular case
incorrectly in exactly that way.

Sending a DELETE followed by a CREATE in this situation would seem to
more clearly communicate the real-world action, and while there will be
times when the sync report simply ends up prompting the client to
perform a full sync, reducing the frequency of those situations should
also be a goal.

On the other hand if we consider this analogous to two consecutive
PROPFIND requests providing a difference of 'that resource is modified'
which clients must necessarily have to cope with already, then it would
be better to send a 'resource modified' in the sync response.

As it stands, it seems to me to be a gotcha and an inevitable a source
of bugs for any client side implementation which sees the create and
makes the easy assumption that it means no resource existed in a local
cache.


> Anyways, I stick to my opinion, slightly extended: Either way is fine
> with me with a slight preference towards having a separate 'created'
> AND 'deleted'. If that would be significantly more difficult for
> servers, lets drop it, if not, lets preserve it.

That does seem the safest approach.

Regards,
				Andrew McMillan.


------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
        Don't you wish you had more energy... or less ambition?
------------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAksdgP0ACgkQjJA0f48GgBI37gCfYA22bKQQugVoio9YA0mhTOCg
w+IAn35zgJMXU4D3Ms7C0AeWMJ5gyjo5
=e3DE
-----END PGP SIGNATURE-----