Re: [VCARDDAV] WebDAv collection sync: last issue

Werner Donné <werner.donne@pincette.biz> Mon, 07 June 2010 17:17 UTC

Return-Path: <werner.donne@pincette.biz>
X-Original-To: vcarddav@core3.amsl.com
Delivered-To: vcarddav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74993A67DB; Mon, 7 Jun 2010 10:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Level:
X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3]
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 oFb9tZdX-yRB; Mon, 7 Jun 2010 10:17:58 -0700 (PDT)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id B45713A688E; Mon, 7 Jun 2010 08:37:38 -0700 (PDT)
Received: by ey-out-2122.google.com with SMTP id 22so204125eye.51 for <multiple recipients>; Mon, 07 Jun 2010 08:36:56 -0700 (PDT)
Received: by 10.213.31.141 with SMTP id y13mr998110ebc.34.1275923479214; Mon, 07 Jun 2010 08:11:19 -0700 (PDT)
Received: from [192.168.0.111] (94-226-41-246.access.telenet.be [94.226.41.246]) by mx.google.com with ESMTPS id 13sm2709127ewy.5.2010.06.07.08.11.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Jun 2010 08:11:18 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: Werner Donné <werner.donne@pincette.biz>
In-Reply-To: <2D7356DA1153057D7AE554D8@caldav.corp.apple.com>
Date: Mon, 07 Jun 2010 17:11:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0296DA16-10E8-47A9-959D-2B9681BEAB36@pincette.biz>
References: <2D7356DA1153057D7AE554D8@caldav.corp.apple.com>
To: Cyrus Daboo <cyrus@daboo.name>
X-Mailer: Apple Mail (2.1078)
X-Mailman-Approved-At: Mon, 07 Jun 2010 11:27:57 -0700
Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org
Subject: Re: [VCARDDAV] WebDAv collection sync: last issue
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jun 2010 17:54:39 -0000

Hi,

I don't see why Depth:infinity should be ruled out from the start. You can let the server decide if the performance penalty is too high or not. A server with a relational system underneath it, for example, can do this with one query.

I don't agree with the "bubble up" principle. A collection changes when its member set changes. Changing a resource that is referred to by one of the members doesn't affect the collection, whether that resource is a collection or not. I think the "bubble up" principal is not consistent with the "getlastmodified" property. It is also not needed if Depth:infinity is supported.

Best regards,

Werner.

On 07 Jun 2010, at 15:57, Cyrus Daboo wrote:

> Hi folks,
> The latest WebDAV collection sync draft is here: <https://datatracker.ietf.org/doc/draft-daboo-webdav-sync/>. We believe we are close to done with this and would like to submit to the IESG soon. However, there is one open issue that we need feedback from implementors on.
> 
> The question is whether collection resources that are immediate children of the collection being targeted for the REPORT should be reported as "modified" if any of their child resources (depth infinity) are modified.
> 
> Key points:
> 
> 1) We have deliberately scoped the REPORT defined in this draft to be Depth:1 only - i.e. it will only report changes to immediate children. Depth:infinity change reporting was ruled out at this time (though eventually we would expect to see it defined if there is interest).
> 
> 2) The first real implementations of this REPORT are being done for CalDAV and CardDAV servers where typically calendar/addressbook collections only have immediate child resources and not collections - so the draft as currently written is fine. (BTW there are already several client and server implementations of this draft that have been tested at various interops). However, my concern is that more "general" WebDAV servers may wish to do reporting of changes to immediate child collections to allow clients to progressively sync an entire hierarchy.
> 
> 3) Reporting changes to immediate child collections requires any change at depth:infinity within those collections to "bubble up" - i.e. a change with a collection changes its DAV:sync-token and the properties of all its parent collections. This potentially places a big performance burden on the server - particularly if it were to choose to support the REPORT on the root resource. In reality servers would probably limit the scope of the report to a reasonable "sub-hierarchy" set (e.g. CalDAV and CardDAV servers would only support the REPORT on calendar or address book home collections and not on any parents of those).
> 
> -- 
> Cyrus Daboo
> 
> 

--
http://www.pincette.biz/
Handling your documents with care, wherever you are.