W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Should CHECKOUT support a TIMEOUT?

From: Clemm, Geoff <gclemm@rational.com>
Date: Sun, 17 Jun 2001 23:26:01 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10350A9DE@SUS-MA1IT01>
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

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

   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.

Received on Sunday, 17 June 2001 23:28:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC