- From: Yaron Goland <yarong@microsoft.com>
- Date: Wed, 26 Mar 1997 00:10:28 -0800
- To: DAV Discussion <davdisc@microsoft.com>
1. UNCHECKOUT 1.1 Problem Definition The term uncheckout actually means two things. One definition is that an uncheckout is the removal of a checkout. The second definition involves transactioning. In this case an uncheckout results in all changes the user has made to the resource since they checked the resource out, being rolled back. 1.2 Proposal With my proposed removal of the CHECKOUT method and its replacement with the LOCK method, the first definition is satisfied with the UNLOCK method. The second definition requires a transactioning system and as such I believe it is beyond the scope of the DAV draft. Those who remember my original position paper on atomic methods will see a contradiction in my view. Indeed, my current view does contradict my original statements. After having spent the last few days thinking about versioning I have come to the conclusion that the rollback UNCHECKOUT requires a transactioning system and that introducing such a system is completely out of scope for DAV. In addition I do not believe that rollback UNCHECKOUT is necessary for a basic interoperable system. 2. DAV.VersionSpace Link 2.1 Problem Definition It is highly probable that a single HTTP server will actually be a front door to a number of other servers, some will support versioning, some will not. Some servers will be able to support versioning of a resource anywhere in their name space and some will only be able to support versioning in specific parts of their name spaces. A mechanism is needed to determine if a server supports versioning at all and if it does, where. 2.2 Proposal I propose introducing the DAV.VersionSpace link. A DAV versioning compliant system must have this link available from *. This link will default to returning a web collection containing a description that indicates which name spaces support versioning and if versioning is automatic or must be requested within those namespaces. 3. History 3.1 Problem Definition One of the most powerful features of a versioned system is the ability to view the entire history of a versioned resource. This information can be built manually by the client by following all the versioning links but this is extremely inefficient. Most servers already maintain the history list, as such it would be good for clients to be able to get this list in one request. 3.2 Proposal I propose that a STRUCTURE method executed on a tree handle return a history. This does not remove the need for the DAV.Versioning.History link. This link is needed to find the tree handle and for proper operation of distributed systems which have no tree handle.
Received on Wednesday, 26 March 1997 03:22:58 UTC