- From: Greg Stein <gstein@lyra.org>
- Date: Thu, 26 Apr 2001 09:20:27 -0700
- To: WebDAV WG <w3c-dist-auth@w3.org>
Fine, you have a nifty answer of replacing one allprop with two requests. But what is the point of tossing allprop, then? If a client is going to get all the names, then fetch them all, they are still going to end up fetching the "time-consuming, computed" properties. The issue isn't tossing allprop, but providing a warning to clients about dealing with expensive computed properties. Removing allprop does not solve the computed problem. Since allprop *is* useful, then there is no reason to remove it. Cheers, -g On Thu, Apr 26, 2001 at 09:21:44AM -0400, Clemm, Geoff wrote: > On Wed, Apr 25, 2001 at 02:36:39PM -0400, Clemm, Geoff wrote: > > I believe it is simpler and more desireable to deprecate the use > > of allprop in all situations, not just Depth:infinity. > > From: Greg Stein [mailto:gstein@lyra.org] > > Nah, that is a bit too extreme. There are clients that may not be > able to interpret all the properties, but still needs to retrieve > them. These are clients that deal with arbitrary properties as > blobs. > > Yes, but that's what the DAV:propname does, while encouraging clients > to be sensible if 5000 property names come back from the DAV:propname > request. > > And in any case, clients are going to have to get used to the fact > that the only way to get all the properties is to first use > DAV:propname (both the versioning and the ACL spec explicitly allow a > server to not return the versioning/acl live properties in response to > a DAV:allprop request). > > allprop is needed to avoid a multiple-trip to fetch names then values. > > In this case "multiple" is "2", and given the cost of computing and > transporting all properties on a resource, the cost of the extra round > trip is insignificant. > > Let's > also consider what would be needed if you're trying to do an allprop on a > tree. You would need to issue a PROPFIND/propname with a Depth:1, then > issue > N PROPFINDs to get each set of properties from the resources. That is > just > *way* too burdensome. > > The client can just union the property names returned by > PROPFIND/propname and make a single depth:1 PROPFIND request for that > list (client side list union is both fast and easy). Commonly, the > propname values for the members will be very similar, so the union of > the property names will be not much longer than what is returned from > a particular member. > > The alternative is a PROPFIND/allprop with Depth:1 as a single fetch for > the > properties of a collection and its members. > > Or a Depth:1 PROPFIND/propname, followed by a Depth:1 PROPFIND > on the unioned list of property names. > > Cheers, > Geoff -- Greg Stein, http://www.lyra.org/
Received on Thursday, 26 April 2001 12:17:48 UTC