Re: [caldav] WebDAv collection sync: last issue

Andrew McMillan <andrew@morphoss.com> Tue, 08 June 2010 04:14 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 A19803A6925; Mon, 7 Jun 2010 21:14:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.554
X-Spam-Level:
X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
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 2B6sATi+W7ro; Mon, 7 Jun 2010 21:14:23 -0700 (PDT)
Received: from mail.morphoss.com (hoppy.mcmillan.net.nz [202.78.240.82]) by core3.amsl.com (Postfix) with ESMTP id 2FED43A6888; Mon, 7 Jun 2010 21:14:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.morphoss.com (Postfix) with ESMTP id 063F22374D; Tue, 8 Jun 2010 16:14:10 +1200 (NZST)
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 xuN2dWpa9Y-q; Tue, 8 Jun 2010 16:13:54 +1200 (NZST)
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 DD8EA23757; Tue, 8 Jun 2010 16:13:53 +1200 (NZST)
From: Andrew McMillan <andrew@morphoss.com>
To: Tim Hare <TimHare@comcast.net>
In-Reply-To: <001f01cb06a4$38a483a0$a9ed8ae0$@net> (sfid-20100608_124828_094303_CD91AB6B)
References: <2D7356DA1153057D7AE554D8@caldav.corp.apple.com> <001f01cb06a4$38a483a0$a9ed8ae0$@net> (sfid-20100608_124828_094303_CD91AB6B)
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ejaWjkx6i6kFmrtII6i/"
Date: Tue, 08 Jun 2010 16:13:52 +1200
Message-ID: <1275970432.3820.9378.camel@happy.home.mcmillan.net.nz>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.1.2
Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org
Subject: Re: [caldav] WebDAv collection sync: last issue
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: Tue, 08 Jun 2010 04:14:25 -0000

On Mon, 2010-06-07 at 20:47 -0400, Tim Hare wrote:
> I am not an implementor, but it seems to me that many Calendar/addressbook
> collections might be depth:2 to accomodate groups like mailing lists ?

Hi Tim,

Yes, that could be one way of implementing such things, though the
specifications for CalDAV explicitly state that calendar collections may
not contain collections.

In DAViCal I did implement multiple-calendars-as-one-calendar by
allowing collections of calendars (or more typically bindings to
calendars) to present as if they were a calendar.  In order to avoid
stepping on the specification I gave these collections a special
resourcetype.

FWIW DAViCal's implementation of WebDAV sync is OK with depth infinity,
since (as the other poster points out) it makes little difference for
query based systems.

Regards,
					Andrew McMillan.

> 
> Tim Hare
> Interested Bystander, Non-Inc.
> 
> -----Original Message-----
> From: caldav-bounces@ietf.org [mailto:caldav-bounces@ietf.org] On Behalf Of
> Cyrus Daboo
> Sent: Monday, June 07, 2010 9:57 AM
> To: w3c-dist-auth@w3.org
> Cc: caldav@ietf.org; vcarddav@ietf.org
> Subject: [caldav] WebDAv collection sync: last issue
> 
> 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).
> 

-- 
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
               Chicken Little only has to be right once.
------------------------------------------------------------------------