Message-ID: <3FF8121C9B6DD111812100805F31FC0D08792D4D@RED-MSG-59> From: Yaron Goland <firstname.lastname@example.org> To: "'Geoffrey M. Clemm'" <email@example.com>, Date: Tue, 19 Jan 1999 19:46:25 -0800 Subject: RE: CHECKIN/CHECKOUT - URNs and Destroying Immutable Resources Reviewing early drafts of anything is always difficult. By their very nature early drafts tend to have lots of unresolved issues. As a reviewer you want to get clarification of those issues but as a working group member you don't want to discourage authors. Then again, speaking from long painful experience, the WebDAV WG's normal review process involves taking the authors out back and beating them senseless. I've tried not to cling to closely to tradition in my own review. I have also decided to break my review into separate posts so as to facilitate conversation. Yaron So Spoke Geoffrey: > Putting a Resource under Version Control > > When a resource is put under version control, it becomes unwriteable. > In order to modify a resource, it must first be checked out, then can > be modified one or more times, and then checked back in to indicate > you are done modifying it. If your CHECKOUT fails, it means someone > else is currently modifying the document, so you should only do a GET > with the understanding that the results are only temporarily valid. > 1) First you say that a resource under version control is unwriteable and then you explain how to modify a resource. I'm confused. I suspect you need to discuss your model a bit. One can infer a lot about the model by reading the rest of the paper but I dislike having to infer, because I tend to infer incorrectly. 2) CHECKOUTs can fail for many reasons wholly unrelated to current use. But the statement does lead one to infer that the proposed versioning system can not support multiple simultaneous checkouts. Is this true? > > Checkout vs. Lock > > Note the distinction between a (write) LOCK and CHECKOUT. The LOCK > takes a resource that is writeable by everyone and temporarily makes > it unwriteable by everyone except the lock holder (until it is > UNLOCK'ed). A CHECKOUT takes a resource that is unwriteable by > everyone, and temporarily makes it writeable (until it is CHECKIN'd). > It is reasonable to apply a LOCK to a checked-out resource, but is > not required. In particular, many systems will decide the LOCK > is irrelevant, since a "friendly" client will delay writing until > it can perform a CHECKOUT, and an "unfriendly" client can just wait > until the UNLOCK and then trash the resource contents at will. > The distinction between shared and exclusive locks should be pointed out. I will defer my points regarding mutable resources to another post. > > Immutable-Revisions > > An immutable-revision is a revision whose contents (and immutable > properties) cannot be changed. More precisely, an attempt to retrieve > the contents or immutable properties of an immutable-revision will > always return the same contents or will fail. Therefore a server can > delete the contents or properties of an immutable-revision (resulting > in a failure when an attempt is made to retrieve those contents or > properties), but can never delete the immutable-revision itself. > If I understand your meaning in saying "never delete the immutable-revision itself" you are implying that a server could nuke all the state associated with the immutable-revision but not a note specifying that once upon a time such a revision did exist and did hold a certain position in the version tree. However the reality is that people will want to destroy even notices of the existence of a revision for any number of reasons, some more nefarious than others. I suspect it is unrealistic of us to expect the protocol to be able to prevent this. There is the additional problem of what to do if the resource is destroyed and its HTTP URL gets re-used. Who will return the "this resource has been nuked" notice? The way the language is current written it would seem that once you assign an HTTP URL to a version of a resource, even if you destroy the resource, you are still required to reserve the HTTP URL so it can return the "this resource doesn't exist anymore" error. I suspect we will find significant opposition to this idea. People tend to get touchy about their HTTP URL namespaces. One alternative is to require that a note be dropped into the version history specifying that there did once exist a version with a set of particular characteristics but its resource has since been destroyed. I don't think this is a good idea because it means that we need to refer to a resource (even one which doesn't currently exist) without the use of a URI. This is likely to muck up the protocol in all sorts of unhappy ways. What we need is a URI which refers to a resource independently of the HTTP URL used to actually retrieve the resource. Which brings us to URNs. I don't propose we actually use URNs, I don't like them very much. But the underlying concept is sound. We should require that all resources have a URI associated with them that meets the same uniqueness requirements we place on lock token URIs. The URIs DO NOT HAVE TO BE RESOLVABLE. If they are, bonus points, but it is not necessary for the protocol to work properly. When a resource is created it must be assigned one of these universally unique URIs. The URI can then be used with the IF header on any requests to an HTTP URL so as to ensure that the request will only succeed if the resource is the same resource as the one specified by the URI. The history graph is then free to refer to both the URI and any known URLs that the resource is available under. If the HTTP URL is changed or the resource is destroyed then the graph will only refer to the universally unique URI. This allows the version to still be refereed to in various operations (such as creating a child) even though it doesn't exist.