- 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