Re: Collection Synchronization for WebDAV

I had to read the draft three times, because it is not really clear 
about this. But finally I think, this REPORT is meant to be always of 
Depth infinity.
This is related to the definition of the synchronization token in 4.2:
 > The server will track each change and
 > provide a synchronization "token" to the client that describes the
 > state of the server at a specific point in time.

This makes sense, if clients always always request a REPORT for the top 
level collection (Depth infinity) or at least for the highest level 
collection, that the client is interested in.

If a client could do REPORT requests of any depth:
The "token" it gets will represent the *state of the whole server* at 
some time, but only part of the cached information of the client would 
be synchronized. If the client some time later, wants to request a 
REPORT on some other part of the cached information (not included in the 
first report), it cannot use this token. So the client would have to 
save the token for every resource separately. This would not be bad in 
itself. Only: if it wants to synchronize part of its cache, where 
different resources have different synchronization token associated, it 
is impossible to evaluate, which is the oldest one, because the draft 
insists, the token has to be
 > an "opaque" string - i.e. the
 > actual string data has no specific meaning or syntax.

The client will have to do a full REPORT request for the top level 
collection (Depth infinity) in this case.

I believe, the draft only makes sense, when REPORTS are always Depth 
infinity for the top level collection. This seems to violate RFC3253 (as 
I understand Julian). For many clients this will also produce far more 
unnecessary traffic, than might be saved by reporting only changes.

I also cannot understand, why it is important or even desirable, for a 
token, to have "no specific meaning".

 > 4.1.  Overview
 >  In order to synchronize data between two entities some form of
 >  synchronization token is required to define the state of the data to
 >  be synchronized at a particular point in time.  That token can then
 >  be used to determine what has changed since that time and the
 >  current time.

To reference to the state of data *at a particular point in time* to get 
information *what has changed since that time*, the most natural choice 
for a token is that particular *point in time*. Why remove its meaning 
and the order?
But this can not be the HTTP-time. The resolution must be far better 
(nanosecond should be possible), so that the server can make sure, that 
  no more than one state change occurs within one time interval.

I believe, the problem of synchronization is strongly related to 
unresolved questions in the basic WebDAV protocol (RFC 4918):
- Last modified time for properties and collections is undefined
- Etag for collections is undefined
- as consequence thereof: it is impossible to define the meaning of 
conditional PROPFIND requests.

Instead of suggesting new REPORTS, tokens and elements, these open 
question should be resolved. I am sure, this would enable conditional 
PROPFIND of any depth for efficient synchroniziation of cached data.

Cheers
Werner

Received on Tuesday, 31 July 2007 20:06:00 UTC