Re: A separate mail on lock and the editing cycle

At 11:02 PM 2/10/97, Fabio Vitali wrote:
>At 20:23 +0100 10-02-1997, Judith Slein wrote:
>>***Fabio - The definition of locking here conflicts with the one that
>>was used in the versioning requirements paper.  More in a separate
>>mail note.
>
>Since what follows reflect a personal opinion, which Judy wasn't agreeing
>enough to put in the official draft document, I am putting it in a personal
>mail to the whole list.
>
>My personal view (which was contained in the versioning requirement paper)
>is that we should work so that, whatever versioning policy will be
>suggested or enforced here, it does not *impose* locks. There are many
>lock-free versioning policies that could be accomodated through HTTP (for
>instance, just to mention personally interesting items, VTML-like markup
>languages). So in the general principles I believe we should allow that the
>request and the granting of a lock are not uniformly implemented in
>systems.

I presented this position at the Cambridge meeting, and it was not
significantly attacked, although the issue of interoperability lurks in the
background here. I think that the focus should be on making clients able to
work with servers _easily_. So things like locking should be defined so
that a client can always do the same things, and be informed by the server
if those are inappropriate.

For instance, declare to edit could return an error: conflicting lock,
without requiring special locking logic on the client end.

This is the same as curently happens with PUT -- you can do it, but you may
not succeed.

Or it could return a "LOCK REQUIRED" message. I think wide deployment of
Web authoring tools means that we need to define a simple client protocol
that can work across all servers, even if the servers have to do some small
extra work. And to me it means that the definitions of lock methods should
all _allow_ NOP-like implementations if that is sensible, so that clients
can use a single simple protocol.

>Another way to put it down is to say that it is always possible
>for the user who has LOCKed an entity to PUT it, while other users may or
>may not depending on the locking policies. In implementations where a
>locking mechanism is not enforced, methods should be available for managing
>multiple checkins.

>This came from the description of the editing cycle which was supposed to
>happen in most situation and that had four steps:
>
>* a resource is RESERVEd (I inform you I'd like to modify that resource,
>  if I may). Servers tracking sessions use this information.
>* a resource is LOCKed (I'd like to start modifying that resource if I may).
>  Servers implementing locking will refuse further LOCK and PUT requests
>  for that resource unless coming from the owner of the lock.
>* a resource is GOTTEN (may I have that resource, please?):
>  a write-only lock on the resource will not prevent any user from GETting
>  the resource. Read-write locks will prevent anyone but the owner of the
>  lock to access it.
>* a resource is PUT (here is the new version of the resource). The owner of
>  the lock is guaranteed to be allowed to PUT the resource or not. All others
>  may or may not depending on the locking policies of the server.
>* a resource is UNLOCKed: (I am finished with this resource, thanks).
>  All users requesting this resource can now have it. LOCKs are also
>  available again.
>* a resource is RELEASEd: (I inform you I have no intention of further
>  modifying this resource). The server can now safely close a modifying
>  session on that resource for that user.
>
>The idea is that every one of these steps is optional, but, depending on
>the pedantry of the server, they may have an effect on the possibility to
>PUT the resource.

And similarly, a client that just blindly performs all these operations can
still work with servers that don't care about them.

>So a lazy server will treat RESERVE, LOCK, UNLOCK and RELEASE as NOOPs and
>always return a success response codes, while strict ones could prevent
>optimistic policies (e.g. it'd accept a PUT for an unlocked resource, but
>won't accept a PUT for a locked one except by the owner of the lock) and
>those even stricter could simply refuse any PUT which has not been
>preceeded by a LOCK.

Exactly.

>If we state the locking issues in a positive manner ("only users owning the
>lock can PUT the resource"), we are imposing a strict locking policy in the
>standard, and make life hard for lock-free systems.

Certainly there are a lot of people in the collaborative work community
trying to get _rid_ of the notion of explicit locks, as they can impede
collaboration. Managing collaboration is very different from managing
document changes in a large organization, but both should be satisfied by
the work of this group.

>By stating it in a
>negative way ("the owner of a lock is guaranteed to be able to PUT the
>resource, and all users can LOCK an unlocked entity"), we guarantee a level
>of common functionality both for locking servers and unlocking servers.

This is really the key point...

>Furthermore, has it has frequently been said in the group, LOCKs are a
>deviation from the statelessness of HTTP, thereby introducing all sorts of
>issues such as expiry of states, removal of states, that a careful phrasing
>could avoid. Furthermore, I believe we could avoid creating a precedent for
>state support in HTTP which could be too heavy a burden to carry.

Right. We may need to support these anyway, but allowing non-locking means
that some (many) implementations need not face these issues unless they
need to.

  -- David

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Tuesday, 11 February 1997 15:34:48 UTC