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

Andrew McMillan <andrew@morphoss.com> Mon, 07 December 2009 22:26 UTC

Return-Path: <andrew@morphoss.com>
X-Original-To: caldav@core3.amsl.com
Delivered-To: caldav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DEED3A69A9; Mon, 7 Dec 2009 14:26:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qme9luW46e9F; Mon, 7 Dec 2009 14:26:36 -0800 (PST)
Received: from mail.morphoss.com (hoppy.mcmillan.net.nz [IPv6:2404:130:0:1::82:0]) by core3.amsl.com (Postfix) with ESMTP id 977F73A69A7; Mon, 7 Dec 2009 14:26:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.morphoss.com (Postfix) with ESMTP id A87E223424; Tue, 8 Dec 2009 11:26:22 +1300 (NZDT)
X-Virus-Scanned: Debian amavisd-new at mail.morphoss.com
Received: from mail.morphoss.com ([127.0.0.1]) by localhost (hoppy.mcmillan.net.nz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id t2PebprUayj5; Tue, 8 Dec 2009 11:26:07 +1300 (NZDT)
Received: from [192.168.55.20] (home.mcmillan.net.nz [202.160.48.75]) (Authenticated sender: andrew@mail.morphoss.com) by mail.morphoss.com (Postfix) with ESMTPSA id 9FBBF23421; Tue, 8 Dec 2009 11:26:07 +1300 (NZDT)
From: Andrew McMillan <andrew@morphoss.com>
To: Helge Hess <helge.hess@opengroupware.org>
In-Reply-To: <15817EA7-94F1-4EDF-AF0C-744F4C319AEC@opengroupware.org> (sfid-20091208_094344_410541_F025B12C)
References: <4B057E6B.7040808@sun.com> <FC4CE9C0-0F2C-4F4A-8F22-DAE3F1AA6B4D@opengroupware.org> <A965C432C02C1101E4F0487F@caldav.corp.apple.com> <15817EA7-94F1-4EDF-AF0C-744F4C319AEC@opengroupware.org> (sfid-20091208_094344_410541_F025B12C)
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Q+gYqDprkZMcLHYRv/8N"
Date: Tue, 08 Dec 2009 11:26:06 +1300
Message-ID: <1260224766.3909.2111.camel@happy.home.mcmillan.net.nz>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1
Cc: Arnaud Quillaud <Arnaud.Quillaud@Sun.COM>, caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org
Subject: Re: [caldav] [VCARDDAV] new webdav sync draft
X-BeenThere: caldav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <caldav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/caldav>
List-Post: <mailto:caldav@ietf.org>
List-Help: <mailto:caldav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2009 22:26:37 -0000

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