RE: Issue: ALLPROP_AND_COMPUTED

   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

Received on Thursday, 26 April 2001 09:19:41 UTC