On Thu, 3 Feb 2000, WJCarpenter wrote: > jamsden> We have to be careful about overloading methods to support > jamsden> client use cases. This will cause the protocol to bloat and I thought we were designing a protocol that is used by the client. Why shouldn't we support it? IMO, returning an XML body in the 423 response is a good idea. It could have a DAV:lockdiscovery element. > jamsden> become complex. It will also reduce interoperability and The spec is how we fix interoperability issues. > jamsden> create situations where one client's use cases conflict with > jamsden> another. Some methods do return failure information that your > jamsden> client can use. > > You also have to allow for the possibility that it's more expensive > for a server to answer questions about the details of a LOCK than it > is to merely answer yes-or-no about a resource being LOCKed. (E.g., a > fixed field in some property table points to a LOCK record stored > elsewhere.) While this is true, we are talking about an error case. Personally, I don't mind taking a few more cycles in an error case. Especially if there is a possibility that the client will be needing that information anyhow. Cheers, -g -- Greg Stein, http://www.lyra.org/Received on Thursday, 3 February 2000 13:43:03 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:53 GMT