RE: Issue: ALLPROP_AND_COMPUTED

To second what Geoff is saying, it really makes the protocol simpler for the
client if they know they CANT rely on allprop.  It doesn't return all
properties; it may fail on some servers.  Better not to use it at all.

lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Thursday, April 26, 2001 9:37 AM
> To: WebDAV WG
> Subject: RE: Issue: ALLPROP_AND_COMPUTED
>
>
> 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 13:49:32 UTC