State-Lock [was Re: Proposal: BIND method]

   From: "John Stracke" <francis@ecal.com>

   >> If we have UNBIND, we need to specify its interaction with LOCK.
   >> Presumably we at least want to prevent an UNBIND on the URL that
   >> was used to create the LOCK, but it might be easier (since
   >> it's the resource that's locked) to prevent any UNBINDs to a
   >> resource while the resource is locked.
   >
   >Hmm.  This boils down to the question of the relationship between bindings
   >and a resource.

   Radical proposal: the binding is truly a separate name for the same
   resource, and there is no discernable distinction between the two
   different names (just like a Unix hardlink).  Then the sequence "BIND
   A to B, UNBIND A" (or the other way around) would be equivalent to a
   MOVE.  In this case, it is clear that a LOCK on one name must lock all
   names, since they're all the same resource.

This would certainly be the cleanest definition for current "LOCK" semantics.

For versioning, I will be proposing a LOCK variant that only locks the
resource state (i.e. the body and the properties), not the URL-to-resource
mapping.  I believe that with these two flavors of LOCK (i.e. one that locks
all the mappings, and one that locks none of the mappings), we have clean
semantics that handle the important use cases.

I will be posting a proposal for the "state-lock" locking variant soon.
One meta-question: This could be a new SLOCK method, or a State
header to the existing LOCK method ... does anyone have a preference?

Cheers,
Geoff

Received on Friday, 9 April 1999 08:44:07 UTC