Next message: Greg Stein: "Re: Where have DAV:revision-set and DAV:working-resource-id/URL-set gone?"
To: ietf-dav-versioning@w3.org
cc: reuterj@ira.uka.de, jjh@ira.uka.de
Date: Thu, 24 Aug 2000 18:31:43 +0200
From: Juergen Reuter <reuterj@ira.uka.de>
Message-ID: <"iraun1.ira.0018901:000824.163147"@ira.uka.de>
Subject: Where have DAV:revision-set and DAV:working-resource-id/URL-set gone?
Hi, all!
From a short look at the 07 draft, I discovered that the DAV:revision-set
and DAV:working-resource-id(or URL)-set have been removed since
draft 04.5.
I think, this is a major drawback. In my current prototype
implementation of a Delta-V client and a server based on 04.5, I apply a
property-report in combination with DAV:revision-set to fetch all
revision properties (including client-defined dead properties) of all
revisions of a versioned resource in a *single* request. Similarly, you
could fetch all properties of all working resources of a versioned
resource in a single request by using the (from various people for future
drafts of 04.5 suggested) DAV:working-resource-URL-set.
Now, the only way I can see to fetch all properties is to request a
DAV:version-tree-report, which does not include user-defined dead
properties, and then, for each revision individually, request a PROPFIND
to fetch the missing properties. As a result, for my implementation I
expect a dramatic slowdown if a versioned resource contains dozens or
hundreds of revisions.
People often argue, that with modern HTTP servers, it is not a
performance problem to deal with many, short requests. But at least for
my particular implementation, it definitely is a problem. And it might
also be a problem for the client. And if it were not at all a problem,
then I wonder, why WebDAV introduced Depth:infinity.
Another important aspect is the management of resources. If, for
example, a versioned resource is stored in an archive (as with RCS,
e.g.), then retrieving properties by hundreds of requests possibly
results in opening, reading and closing the archive hundreds of times.
If the properties are retrieved in a single request, it is much more
easier to implement a server that opens, reads and closes the archive
only once to retrieve all properties.
Hence, I strongly vote for a possibility to fetch all properties
(including user-defined dead properties) in a single request, as was
possible with the former revision-set property.
Any comments appreciated.
From my quick look at 07, I found some more small issues (beg your
pardon, if they have already been discussed!):
Section 3.4.3:
==============
What is a "reasonable approximation"? A maximal difference of one
second? A millisecond? Please explain the reason for this
requirement so that the reader gets an idea of what is reasonable.
Section 3.5.1:
==============
Mmh, the former DAV:predecessor-set had the advantage that I could use
the same code for revisions and working resources when traversing through
the revision tree including working resources as special leaves of the
tree. But DAV:checked-out probably better reflects the concept of
working resources. So I am not really sure what is better.
Section 4.1:
============
replace "label" -> "label name" to be consistent with 3.4.4.
<nitpicking>
Change wording: "A Target-Selector header has no effect if the
request-URL does not identify a version selector." Because a target
selector does not affect the request-URL, but its interpretation.
</nitpicking>
Section 6.1:
============
Replace "version controlled resource" with "version selector resource"
for consistency with other sections.
Section 6.6:
============
Is it really <!ELEMENT set (label-name)>
or rather <!ELEMENT set (label-name-set)> ?
"If DAV:add or DAV:replace is specified, the specified label selects ..."
DAV:replace is undefined.
The difference between set and add is unclear.
Section 21:
===========
For consistency, replace DeltaV -> Delta-V (2x)
Reminder:
=========
* still conversion problems with Word->HTML:
- ".." in table of contents
- formatting of ascii art: missing <PRE>...</PRE>
* write section for IANA editor to assign status code numbers 4xx
=======================
Bye,
Juergen