RE: Issue: ALLPROP_AND_COMPUTED

Oops.  I meant to say "ignores the 2518 requirement
that by default a PROPFIND must be Depth:infinity".

Cheers,
Geoff

-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@Rational.Com]
Sent: Sunday, May 06, 2001 10:27 AM
To: w3c-dist-auth@w3c.org
Subject: RE: Issue: ALLPROP_AND_COMPUTED


I personally would like to be a bit more proactive than
"let's wait until it breaks before worrying about it".
By then, all the broken, non-interoperable clients and
servers have been deployed, and its too late for a clean
or simple fix.

The fact that DAV:allprop can be efficiently implemented
by a server that supports only the 2518 properties and the
relatively few number of dead properties that clients
create these days is not the problem.  It is the fact that
large numbers of expensive to compute properties are currently
being defined, both in the protocol and as custom properties,
that raises the concern.

Having clients "discover and adjust" is not a good technique
for achieving interoperability.  The fact that
DAV4J ignores the 2518 requirement
that by default a PROPFIND MUST be DAV:allprop, is a good
example of the interoperability problems that arise when
the protocol makes a poor choice of exposing functionality.
A client writer would need to be aware of the various
"variations from the protocol" that have been chosen
by various server implementors (e.g. returning "errors"
on requests that the server feels are "too expensive"),
and then try a sequence of alternative requests to get the
desired result.

Cheers,
Geoff 

-----Original Message-----
From: Jim Amsden [mailto:jamsden@us.ibm.com]
Sent: Sunday, May 06, 2001 9:17 AM
To: w3c-dist-auth@w3c.org
Subject: Re: Issue: ALLPROP_AND_COMPUTED


Greg (and Jason seems to agree):

Personally, I would recommend leaving it just as it is, with a note in the
spec that the server can return <this> error in certain cases. The client
should interpret that as "whoops. we asked too much" and back off to a
nicer
algorithm. (and better yet, just start with the nice one)

I also agree, but think the default should probably be changed to depth 0.
Althought clients are free to deal with that too. DAV4J's
Resource.getProperties() method uses a depth 0 default in its marshalling.
It doesn't really matter what the protocol specifies. Clients can use what
they want. allprop is just one option for getting properties. If servers
are slow or fail on it, client writers will discover this and adjust
accordingly. I don't think there's any need for the protocol to try to
solve it any further. Some servers can return all the properties pretty
fast. As slow as the DAV4J server is on most operations, it can return all
the properties pretty fast since they're all in a single XML document.
Depth infinity isn't that slow either, but their might be a lot of files
returned!

Received on Sunday, 6 May 2001 17:44:33 UTC