Cyrus Daboo | 7 Jun 2010 15:57
Favicon

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 
(Continue reading)

Tim Hare | 8 Jun 2010 02:47
Picon

Re: WebDAv collection sync: last issue

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 ?

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: caldav-bounces <at> ietf.org [mailto:caldav-bounces <at> ietf.org] On Behalf Of
Cyrus Daboo
Sent: Monday, June 07, 2010 9:57 AM
To: w3c-dist-auth <at> w3.org
Cc: caldav <at> ietf.org; vcarddav <at> 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).
(Continue reading)

Andrew McMillan | 8 Jun 2010 06:13

Re: WebDAv collection sync: last issue

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 <at> ietf.org [mailto:caldav-bounces <at> ietf.org] On Behalf Of
> Cyrus Daboo
(Continue reading)

Julian Reschke | 8 Jun 2010 09:11
Picon
Picon

Re: [VCARDDAV] WebDAv collection sync: last issue

On 08.06.2010 02:47, 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 ?
>
> Tim Hare
> Interested Bystander, Non-Inc.

There is no "Depth: 2" unless we introduce it. The Depth header is 
inherited from RFC 4918 (see 
<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.10.2>).

Best regards, Julian
Roberto Polli | 8 Jun 2010 11:15
Picon
Favicon

Re: WebDAv collection sync: last issue

On Monday 07 June 2010 15:57:09 Cyrus Daboo wrote:
> 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.
aware of the performance issue, I think that the right behavior should be 
depth: infinity.

while the performance issue should be solved by the storage layer (eg. 
filesystem or database, which perform that op quite nicely)
and while the average depth level rarely goes above 4 (and in most cases it's 
3 or 2) 

Having depth:1 can be confusing, as that feature is supposed to notify whether 
I have to sync or not a given folder.

My 2 cents+Peace,
R.

--

-- 

Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
Tel. cel +39.340.6522736
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo 
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene 
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio 
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto 
(Continue reading)

Werner Donné | 7 Jun 2010 17:11

Re: WebDAv collection sync: last issue

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
(Continue reading)

Julian Reschke | 8 Jun 2010 09:14
Picon
Picon

Re: [VCARDDAV] WebDAv collection sync: last issue

On 07.06.2010 17:11, Werner Donné wrote:
> 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.

Agreed.

In particular: defining a report works by defining it for Depth: 0. The 
semantics for Depth: 1 and Depth: infinity follow by the definition in 
RFC 3253.

It's probably *really* time to pull the definition of REPORT out of RFC 
3253 and place it into a separate spec, including more rationale, 
recommendations for defining new reports, and examples.

Best regards, Julian
Julian Reschke | 13 Dec 2011 22:50
Picon
Picon

Last Call: <draft-daboo-webdav-sync-06.txt> (Collection Synchronization for WebDAV) to Proposed Standard

On 2010-06-08 09:14, Julian Reschke wrote:
> On 07.06.2010 17:11, Werner Donné wrote:
>> 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.
>
> Agreed.
>
> In particular: defining a report works by defining it for Depth: 0. The
> semantics for Depth: 1 and Depth: infinity follow by the definition in
> RFC 3253.
>
> It's probably *really* time to pull the definition of REPORT out of RFC
> 3253 and place it into a separate spec, including more rationale,
> recommendations for defining new reports, and examples.
>
(Continue reading)


Gmane