Checkout

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