- From: Jim Amsden <jamsden@us.ibm.com>
- Date: Sun, 6 May 2001 16:08:24 -0400
- To: w3c-dist-auth@w3c.org
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