- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 21 Feb 2002 09:51:41 +0100
- To: "Lisa Dusseault" <lisa@xythos.com>, "Webdav WG" <w3c-dist-auth@w3c.org>
Lisa, I don't agree at all with the deprecation, and I don't think that there was consensus about this. The draft says: Clients MUST not send allprop requests in any form (either the empty body PROPFIND or the specific allprop element), because allprop is being removed. WebDAV servers increasingly have expensively-calculated or lengthy properties (see DeltaV and ACL specifications [TODO: ref RFC when available]) and do not return all properties already. Instead, WebDAV clients can use propname requests to discover what properties exist, and request named properties when retrieving values. A WebDAV server MAY omit certain live properties from other specifications when responding to an allprop request from an older client, and MAY return only custom (dead) properties and those defined in this specification. In particular: "WebDAV servers increasingly have expensively-calculated or lengthy properties (see DeltaV and ACL specifications [TODO: ref RFC when available]) and do not return all properties already." -> This is an argument for *restricting* the set of properties returned on allprop, not for removing the feature (and that's what deltaV does). "Instead, WebDAV clients can use propname requests to discover what properties exist, and request named properties when retrieving values." -> And the benefit is? The client will issue two calls: first it will use propname to find the list of properties. Computing whether a live property exists maybe as expensive as computing it (for instance, to find out whether something is checked in/out). *Then* it will submit PROPFIND / prop will all these properties. So as compared to the current situation, the server may have to compute things twice which wouldn't have been computed at all before (since asking for allprop wouldn't require computing live deltaV properties). -> Even leaving the propname vs live properties issue out, this doesn't make sense. You are removing a working and interoperable protocol feature without sound reason. As a fallback you offer a workaround which requires at least one additional trip to the server, possibly heavy computation on the client (computing the set of all property names on the members of a collection) and then additional marshalling (when I do a PROPFIND/prop with a long list of (dead) property names on a collection with depth 1, the server will have to 404-status them for many collection members). -> I agree that PROPFIND needs to be cleaned up, but this is not the way to go. The draft continues with: "A WebDAV server MAY omit certain live properties from other specifications when responding to an allprop request from an older client, and MAY return only custom (dead) properties and those defined in this specification." -> I think this may make sense. We will however need a way to get all dead properties and a set of named properties with a single request (see [1]). We may also have to find a way for a client to discover that something is a live property. [1] <http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-allprop-include-l atest.html>
Received on Thursday, 21 February 2002 03:52:15 UTC