- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sun, 17 Jun 2001 23:26:01 -0400
- To: ietf-dav-versioning@w3.org
From: John Hall [mailto:johnhall@evergo.net] It seems pretty easy to add "Note: any client can issue an UNCHECKOUT". Any client can issue any request. I assume that you meant something more significant than that? The spec says that deleting the working resource results in an implicit UNCHECKOUT. No, it says that a CHECKOUT that created a working resource is cancelled by deleting that working resource. An UNCHECKOUT request is only defined for a version-controlled resource, not a working resource, because the key semantic of UNCHECKOUT is that it returns the version-controlled resource back to the state it had before the CHECKOUT. This makes no sense for a working resource. But what happens to the working resource if you do an UNCHECKOUT? Should it be deleted? It is undefined. Does a WRITE-LOCK prevent an UNCHECKOUT from succeeding unless you hold the LOCK? That would be a round about way of adding a timeout to a CHECKOUT request. A write-lock on a version-controlled resource prevents an UNCHECKOUT from succeeding if that UNCHECKOUT would change the content or dead properties of that VCR. The only connection between a lock timeout and a checkout is if the checkout was an automatic checkout resulting from updating a write-locked checked-in VCR. In this case, the result of the lock expiration would be an automatic checkin, not an automatic UNCHECKOUT. If a WRITE-LOCK prevents an UNCHECKOUT unless the Locks is held and specified, then someone with a working resource could lock the VCR first. In that case, perhaps the VCR and the working resource should share the lock? The VCR and the working resource are two separate resources, with two separate URL's, with their own set of locks. It would have to be an incredibly compelling use case to cause us to "link" the locks of two distinct resources. The versioning protocol and the locking protocol have been carefully kept as orthogonal as possible so that they can evolve independently. Cheers, Geoff
Received on Sunday, 17 June 2001 23:28:24 UTC