Re: A separate mail on lock and the editing cycle

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