Re: Issue: ALLPROP_AND_COMPUTED

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