A separate mail on lock and the editing cycle

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.

In the versioning requirements, it is explicitly said that while an
UNLOCKED entity is surely available to everybody requesting it, LOCKED
entities may and may not be available (usually NOT) to everyone who is not
the author. 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.

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.

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

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.

Received on Monday, 10 February 1997 18:15:53 UTC