- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Tue, 22 May 2001 16:58:47 +0200
- To: <ietf-dav-versioning@w3.org>
> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von Clemm, Geoff
> Gesendet: Dienstag, 22. Mai 2001 16:24
> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
>
> ... I found that the versioning properties did
> vanish from PROPFIND/allprop in revision 14.1 of the draft.
>
> With the current state of things, I'd have to do 2 PROPFINDS (one
> allprop to catch all dead properties, one specific DAV:supported*
> to know about versioning and resource status).
>
> Versioning properties are included in PROPFIND/DAV:propname, so you do
Oops. Our understanding was that DAV:propname behaves analog to DAV:allprop
and will not include the versioning properties. I see that "propname" is
not mentioned in ietf-deltav-versioning-15. Could you clarify?
> need two requests, but they would be a PROPFIND/DAV:propname request,
> and then a PROPFIND on the list of properties returned by the
> PROPFIND/DAV:propname.
My example was referring back to your explanation about the true usefulness
of DAV:supported-live-property-set. Since I would like to present all
dead and standard properties (propfind/allprop), plus know what type
of resource I have got, I would need to get DAV:supported-live-property-set
as well (and hopefully _not_ more).
> But I would think hard about ever having an application blindly ask
> for all the properties on a set of resources. These properties could
> be very expensive to compute, and since you have no way of determining
> how long these property values are valid, caching them is of
> questionable value.
I totally agree.
> Has it been discussed already (could not find it in the archive) to
> enhance allprop by allowing the client to specify additional
> properties?
> This would make the body of a PROPFIND look like
>
> <propfind xmlns="DAV:">
> <allprop>
> <prop>
> <supported-method-set/>
> <supported-live-property-set/>
> </prop>
> </propfind>
>
> and the result would be the joined set of a PROPFIND/allprop
> and PROPFIND/prop.
>
> (The only related thing I could find was the "WebDAV PROPFIND
> Extension To List Specified Namespaces" Draft from August 1999.
> Which is a nice draft, but I assume it is too late to move the
> versioning props into a separate namespace...)
>
> Because of the issues mentioned above (i.e. expense of computing live
> property values, and the absence of support for reliable property
> value caching), the versioning protocol does not worry about the extra
> round required to obtain "all versioning properties". A live property
> is effectively a "query" on the state of a resource. Would one
> expect to be able to "perform all known queries on this resource"
> in a single round trip?
Certainly not. Maybe I need to supply a more specific example:
My code could be used by a WebFolder like application, which knows
about basic versioning. It would need to know for a collection
a) the "standard" RFC 2518 Properties, plus all dead properties (which
it might make use of internally)
b) if a resource is versionable (to allow context menu "make
versionable...")
c) if a resource is version-controlled, e.g. checked-in/out (to allow
context menu
entries like "check in..." etc.)
d) if a resource is versioned, e.g. part of history (to indicate that it
cannot be altered)
For this, it is useful to enhance PROPFIND/allprop to make only one request
against the WebDAV server. We did this in our implementation with good
results
like:
<D:propfind xmlns:D="DAV:">
<D:allprop/>
<ext:include xmlns:ext="http://greenbytes.de/ns/tests">
<D:checked-in/>
<D:checked-out/>
<D:version-name/>
</ext:include>
</D:propfind>
This gives us good performance and also works against current
implementations
of moddav, IIS 5.0 and SharePoint RC1.
Regards, Stefan
Received on Tuesday, 22 May 2001 10:59:50 UTC