- From: Steve Carter <SRCarter@novell.com>
- Date: Tue, 11 Feb 1997 13:44:53 -0700
- To: fabio@cs.unibo.it, w3c-dist-auth@w3.org
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.
-src
Steve Carter
Novell
GroupWare CTO
srcarter@novell.com
801-228-5175
801-228-5176 fax
>>> Fabio Vitali <fabio@cs.unibo.it> 02/10/97 04:16PM >>>
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 Tuesday, 11 February 1997 15:50:00 UTC