- From: Yaron Goland <yarong@microsoft.com>
- Date: Wed, 26 Mar 1997 00:10:48 -0800
- To: DAV Discussion <davdisc@microsoft.com>
1. CHECKOUT 1.1 Problem Description It is impossible to define what the archetypal checkout does because it is used for so many different things. A fairly informal survey of the versioning software field has shown that checkout is used for: * Reserving a version token to be used on check-in * Specifying a lock type * Specifying a notification of intent * Specifying who may see the notification of intent * Specifying a location to save a copy of the checked out resource * Declaring a reason for the checkout In trying to meet all these requirements the DAV authors created one of the most powerful versioning systems ever proposed, alas the system is so powerful that it is, in reality, totally non-interoperable. No client could implement all its features and no server would want to support them all. As such the DAV group called for a radical simplification. Furthermore this simplified versioning system must take into consideration issues arising out of distributed operation. Mainstream versioning clients assume they are speaking to a single server, even though the server they are speaking to may be part of a fully distributed and replicated system. The DAV versioning system must work with such systems but it must also be able to handle distributed versioning servers that have no direct communication with each other. The problem I believe needs to be solved is the ability to declare an intent to edit a resource and the ability of principals with equivalent access rights to assert some control over the ability to create new versions of a resource. At a minimum that control is no control. At the maximum, that control is the restriction of the ability to control a new resource down to a single principal. 1.2 Proposal I believe that the central operation of checkout is the lock. Some systems use an advisory lock while others use an exclusive write lock. As such, I propose that we do not have a CHECKOUT method but rather use the LOCK method. The notification of intent to edit will be provided by the DAV.LockInfo link. I believe that the question of access to the DAV.LockInfo information is one that should not be settled through the checkout process. Rather it is a question of access rights, an issue the DAV group has ruled out of scope. I do not believe that getting a version of the checked out resource should be provided for in the lock. In HTTP one gets resources with the GET method and in general, repeating a key piece of functionality as a side effect of a method seems like bad design. There are, however, times when a client will want to GET a copy of the resource, but have that working copy kept on the server. For this case, I propose the introduction of the Save-Response header. The previously defined Comment header handles declaring a reason for the checkout. The final issue is the reservation of a version identifier for use on check-in. I propose that we do not overload lock with this functionality. Shoving a registration scheme into a lock violates design principal 2, that methods should only perform a single action at a time. If a client wishes to reserve a version identifier, they can always create an empty resource and mark it as specified in the section on check-in. 1.3 Example LOCK http://www.uci.edu/editing/http1.2 HTTP/1.1 Lock-Info: LockType = Write LockScope = Exclusive TimeOut: NONE Comment: "I want to update the versioning references" LockOwner: http://www.uci.edu//Roy_Fielding This request exclusively locks the resource http://www.uci.edu/editing/http1.2 with no time out, a short comment, and an identifier of who did the check out. It is up to the system to determine what information it will use in the DAV.LockInfo resource. For example, it may display the LockOwner information or it may use its own records tied to its authentication system.
Received on Wednesday, 26 March 1997 03:10:45 UTC