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

Re: Issue: ALLPROP_AND_COMPUTED

From: <Tim_Ellison@uk.ibm.com>
Date: Fri, 4 May 2001 09:16:54 +0100
To: w3c-dist-auth@w3.org
Message-ID: <80256A42.002D7F5E.00@d06mta07.portsmouth.uk.ibm.com>


Greg Stein <gstein@lyra.org> wrote:

> On Wed, May 02, 2001 at 11:53:27PM -0400, Clemm, Geoff wrote:
> > I am adamantly opposed to DAV:allprop.  In the context of
> > computed live properties, a client should never blindly ask
> > for all property values ... it should always first ask for
> > DAV:propname, and then use the subset that it can use.
>
> Euh, how does the propname help the computed live prop case?
> If I fetch all the names, then fetch the values, then I've
> still slammed the server with a bunch of computed props.

I think the key part of Geoff's post is "the subset that it can use".  The
problem with allprop is that it will return all the live properties
irrespective of whether the client is aware of the properties' semantics.
Sometimes this is what the client wants, say if it is naively displaying a
property sheet; but most likely it is not since there is no way for the
client to interpret the values or know if/how they can be changed.

> Removing allprop does not help this scenario at all.

It's the old NRA argument -- allprop doesn't kill servers, clients kill
servers ;-)

> > The WebDAV versioning extensions explicitly allows a server to
> > *not* return the versioning properties in response to a
> > DAV:allprop request, so DAV:propname will be the only reliable
> > way of obtaining all the properties.
>
> When did that go in? That seems to be a direct violation of RFC 2518.

I have to agree that it is a stealth action to undermine (the effects of)
allprop.

> > Finally, the fact that
> > PROPFIND/DAV:allprop is trivially replaceable with two PROPFIND
> > calls (the first being PROPFIND/DAV:propname) makes DAV:allprop
> > superfluous (in addition to being inadvisable).
>
> It is *NOT* trivial. If you want to do a Depth:1, then the client
> is going to have to create a union of all the resources' prop names,
> then do the fetch for those props. Next, it will need to deal with
> the 404 that it will get for the props that weren't available on all
> resources.
>
> Trivial? Bah.

I'd say that was pretty trivial.

Tim
Received on Friday, 4 May 2001 04:17:41 GMT

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