Re: Collection Synchronization for WebDAV

Cyrus Daboo wrote:
> 
> Hi folks, FYI. Comments welcome.
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> Title        : Collection Synchronization for WebDAV Author(s)    :
> C. Daboo Filename    : draft-daboo-webdav-sync-00.txt Pages        :
> 14 Date        : 2007-7-3
> 
> 
> This specification defines an extension to WebDAV that allows 
> efficient synchronization of the contents of a WebDAV collection.
> 
> 
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-daboo-webdav-sync-00.txt
> 
> 

Section 1:
> However this does not scale well to large collections as the XML
> response to the PROPFIND response will grow with the collection size.
> 
The implication is that the response to a <sync-collection> report
*won't* grow with the collection size. I think what you're trying to say
is that the size of the response to PROPFIND is proportional to the
number of resources in the collection, whereas the size of the response
to <sync-collection> is proportional to the number of *changed*
resources in the collection. The new report might be smaller than the
propfind, but it isn't necessarily going to scale any better, depending
on the nature of activity in the collection.


Section 4.1, para 3:

> The is specification

Typo.


Section 4.2:

> A simple implementation of such a token would be a numeric counter
> that counts each change as it occurs and relates that change to the
> specific object that changed.

It's hard to see how a 'numeric counter' can relate anything to anything
else - a counter can only count. However I can imagine implementing the
token as an index into a register of changes; the server would maintain
a changelog, and a given token would select all changes that have
occurred beyond a certain point.


> The request body MUST be a DAV:sync-collection XML element (see 
> Section 5.1, which MUST contain one DAV:sync-token XML element, and
> optionally a DAV:propstat XML element.

That should read "and optionally a dav:prop XML element.", for
consistency with your examples and with the DTD fragments.

> A status code of '201 Created' is used to indicate resources that are
> new.

It's not obvious to me that this is necessary; a client can tell that a
resource is new if it has a <sync-response> element in the report, and
the resource doesn't exist in the client's cache. Allowing a 200 status
in such cases might simplify some server implementations.

Open issues:

1. Distinguishing between property changes and content changes struck me
    immediately as something that was lacking. If you don't distinguish
    between them, then a client must make a minimum of two requests to
    ensure that it is up-to-date. In the case of a CalDAV server and a
    calendar-collection, the client could update either or both the
    cached properties and the content in a single transaction (using a
    <calendar-query> report).


5. Losing <read> on a resource doesn't necessarily prevent you from
    being able to see it; it just prevents you from being able to GET it
    (I think that is implementation-dependent). That a resource exists
    but cannot be read, could be signalled using a 401. If <read>
    controls the ability to see a resource at all, then I would expect
    the loss of <read> to have the same effect as the removal of the
    resource - 404.
    But that raises the question of what to do with newly-created
    resources that you can see, but can't read; I suppose that should
    result in a 401 for the new resource.
    Consider a server that implements a <read-properties> privilege. If
    the user has lost <read-properties> on some resource, and the
    properties themselves have changed, then presumably the client should
    delete properties from its cache.
    In general, it seems to me that the interaction of this spec with ACL
    is going to be difficult, because ACL grants implementors a lot of
    latitude. The various cases need to be worked out carefully.

-- 
Jack.

Received on Wednesday, 4 July 2007 08:52:19 UTC