- From: Fabio Vitali <fabio@cs.unibo.it>
- Date: Mon, 10 Feb 1997 23:02:21 +0100
- To: w3c-dist-auth@w3.org
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