Re: A separate mail on lock and the editing cycle

Comments interleaved:

>>>> Fabio Vitali <fabio@CS.UniBO.IT> 02/11/97 05:07PM >>>
>>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.

The "design meeting" consisted of two week-long meetings among the authors
to prepare the specification that was presented. In no way was it internal to 
Novell or any other vendor.
>
>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.

Several at the Irvine meeting would remind you here that there are versioning systems
which do not use LOCK and UNLOCK, etc but rely on other methods of conflict
resolution. Because of the many models that are supported in the industry we have
not beeen able to convince ourselves that there is a universal versioning/editing
cycle that will allow "all clients" to interoperate.

>
>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.
>

I'm off-site right now and will elaborate on my conclusions at a later date.

>Thanks
>
>Fabio


-src

Received on Tuesday, 18 February 1997 10:02:29 UTC