WebDAv collection sync: last issue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

WebDAv collection sync: last issue

Cyrus Daboo-2
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


Reply | Threaded
Open this post in threaded view
|

Re: WebDAv collection sync: last issue

Werner Donné-2
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.



Reply | Threaded
Open this post in threaded view
|

Re: [caldav] WebDAv collection sync: last issue

Andrew McMillan-5
In reply to this post by Cyrus Daboo-2
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: [hidden email] [mailto:[hidden email]] On Behalf Of
> Cyrus Daboo
> Sent: Monday, June 07, 2010 9:57 AM
> To: [hidden email]
> Cc: [hidden email]; [hidden email]
> 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.
------------------------------------------------------------------------


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [VCARDDAV] [caldav] WebDAv collection sync: last issue

Julian Reschke
In reply to this post by Cyrus Daboo-2
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

Reply | Threaded
Open this post in threaded view
|

Re: [VCARDDAV] WebDAv collection sync: last issue

Julian Reschke
In reply to this post by Werner Donné-2
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

Reply | Threaded
Open this post in threaded view
|

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

Julian Reschke
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.
>
> Best regards, Julian

It seems to me that this issue was never addressed.

As defined right now, the way REPORT is used doesn't seem to be
compatible with the definition of REPORT in RFC 3253, and the definition
of the Depth: header field in RFC 4918.

Unless I'm missing something, this will be a problem for any
implementation that tries to implement the sync report based on a
generic WebDAV reporting framework.

Best regards, Julian