W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

RE: Issue: ALLPROP_AND_COMPUTED

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 26 Apr 2001 12:37:00 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E239B@SUS-MA1IT01>
To: WebDAV WG <w3c-dist-auth@w3.org>
The reason I want to get rid of DAV:allprop is that I believe the
protocol is simpler without it.  Otherwise you have to define allprop,
define
its behavior, and then constrain its usage to only be Depth:0 or
Depth:1.  Since there is a perfectly good 2 request alternative to
allprop, I believe we have one of those golden opportunities to
actually *simpilify* the protocol, instead of layering on yet one
more obscure rule (i.e. the "allprop only with Depth:0 or Depth:1"
rule).

Cheers,
Geoff

-----Original Message-----
From: Greg Stein [mailto:gstein@lyra.org]
Sent: Thursday, April 26, 2001 12:20 PM
To: WebDAV WG
Subject: 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:34:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:56 GMT