RE: Issue: ALLPROP_AND_COMPUTED

Geoff says:

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.

This is not really an interoperability issue unless servers routinely fail
allprop requests. I don't think the protocol anticipate all the policies of
clients might choose to use in requests. That's like saying all distributed
object applications that make a lot of fine-grained remote procedure calls
should be prevented from doing so by redesigning RPC protocols so only some
new kind of course-grained service calls can be made.

DAV4J does not introduce an interoperability problem with its use of
Resource.getProperties(). The protocol on the wire is DAV compliant. This
(client) method simply marshalls its default depth as 0 instead of
infinity. If you want infinity, you need to say so. The DAV4J server is
unaware of this convention, and if it gets a PROPFIND without a depth
header, it does depth infinity.

I'm still inclined to leave allprop alone, and just not use it, or use it
very carefully, in any clients I might write. The DAV4J cross-server copy
does rely in allprop to copy the resource properties.

Received on Sunday, 6 May 2001 16:12:32 UTC