- From: Fabio Vitali <fabio@CS.UniBO.IT>
- Date: Wed, 12 Feb 1997 01:07:40 +0100
- To: Steve Carter <SRCarter@novell.com>
- Cc: w3c-dist-auth@w3.org
At 21:44 +0100 11-02-1997, Steve Carter wrote: >I understand what you are trying to do by making LOCK a loose >interpretation and allowing "lazy" servers to respond as desired. >Unfortunately, by permitting *any* response (for instance, returning a >success code on a lock when you are a lazy server and didn't really lock >it) will cause great heartache in interoperability land. > >I feel we need to do two things ( back on my soap box from Irvine): >1. provide for interoperability >2. provide a launching platform for the future. > >Neither is served if we do not have a strict and *expected* result from >LOCK. If you have a lazy server and I specify "LOCK" that resource, I >expect the server to return a failure code because the resource is NOT >LOCKED. > >As a design team we pulled back from the soft LOCK model that was first >proposed because nobody could count on it for anything. In our next >design meeting I'll make sure that your comments here are gone over >completely so that we can verify that "non-locking versioning systems" >are represented in the design. But we must also allow "check-out >versioning systems" and "lock versioning system" to be represented as >well. Well, ok. As long as the non-locking policy can be handled as well, I'm fine with what you say. I'm not sure though if by "design meeting" you refer to something internal to Novell, or to something WebDAV. Maybe "requirements" and "design" were mixed again in the document, and we were already suggesting solutions instead of needs. This is a subtle issue, where requirements end and design starts. Nonetheless, design-wise, I wonder. Having a fixed editing cycle (RESERVE, LOCK, GET, PUT, UNLOCK, RELEASE) with optional non-operative methods could allow simple clients to work in all situations, while requiring reliable behaviour in "strong" methods (RESERVE and LOCK either perform strongly, or return an error) would imply a somewhat more complex client behaviour, too, since it would have to provide management of all the situations that could arise, depending on the kind of server I am dealing with. This is clearly a design trade-off, which I would like explored. You say you have already discussed it and preferred a more complex client-server protocol to unreliable methods. I trust you, but would like you to spend a few more words on your conclusions. Thanks Fabio
Received on Wednesday, 12 February 1997 10:10:49 UTC