Re: [caldav] new webdav sync draft

Helge Hess <helge.hess@opengroupware.org> Mon, 07 December 2009 20:43 UTC

Return-Path: <helge.hess@opengroupware.org>
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 7E6F73A6988; Mon, 7 Dec 2009 12:43:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level:
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[AWL=-0.589, 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 HSItqFRPwEKP; Mon, 7 Dec 2009 12:43:31 -0800 (PST)
Received: from mailhub.opengroupware.org (mailhub.opengroupware.org [213.211.192.144]) by core3.amsl.com (Postfix) with ESMTP id 88F3D3A6930; Mon, 7 Dec 2009 12:43:31 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhub.opengroupware.org (OPENGROUPWARE.ORG MAILHUB) with ESMTP id A5817228253; Mon, 7 Dec 2009 21:43:19 +0100 (CET)
X-Virus-Scanned: amavisd-new at opengroupware.org
Received: from mailhub.opengroupware.org ([127.0.0.1]) by localhost (mailhub.opengroupware.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTMEopb91iD0; Mon, 7 Dec 2009 21:43:18 +0100 (CET)
Received: from [192.168.0.111] (91-65-6-214-dynip.superkabel.de [91.65.6.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailhub.opengroupware.org (OPENGROUPWARE.ORG MAILHUB) with ESMTPSA id D4CAB2281D3; Mon, 7 Dec 2009 21:43:17 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Helge Hess <helge.hess@opengroupware.org>
In-Reply-To: <A965C432C02C1101E4F0487F@caldav.corp.apple.com>
Date: Mon, 07 Dec 2009 21:43:16 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <15817EA7-94F1-4EDF-AF0C-744F4C319AEC@opengroupware.org>
References: <4B057E6B.7040808@sun.com> <FC4CE9C0-0F2C-4F4A-8F22-DAE3F1AA6B4D@opengroupware.org> <A965C432C02C1101E4F0487F@caldav.corp.apple.com>
To: Cyrus Daboo <cyrus@daboo.name>
X-Mailer: Apple Mail (2.1077)
Cc: Arnaud Quillaud <Arnaud.Quillaud@Sun.COM>, caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org
Subject: Re: [caldav] 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 20:43:32 -0000

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.

Now thinking about it, I think it might be an issue if a resource in the cache is replaced with an entirely new resource.
Eg the client might have (real world: is likely to have) extra client-side data which is only valid for the 'old' resource.

But then, the client can't discover that specific situation with the regular PROPFIND either. And it won't be terribly common, as new URLs usually change in most systems.

> However, I think the reality is that clients are going to have to accept the fact that there may be false positives (though hopefully never false negatives) so the prudent thing to do is always do a proper match between the server reported results and the full cache they currently have. Maybe we need a statement clarify that.

I think performance might be a real world issue with restricted clients (mobile) and large folders, where a key lookup does have a cost.

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.

:-)

Greets,
  Helge