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
|
