- From: Greg Stein <gstein@lyra.org>
- Date: Thu, 3 Feb 2000 10:43:39 -0800 (PST)
- To: w3c-dist-auth@w3.org
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 UTC