Re: resourcetype locknull

My "summary" of the proposal was too terse.  When I said:

   "if you are going to do depth locking, it should be static,
   i.e. it should be a lock on the current members of the collection"

I should have said:

  "... it should be a lock on the collection and its current members"

So every successful LOCK locks at least one resource (with no
Depth header, it is exactly one resource).  A key point here
(which I managed to successfully obscure :-) is that a collection
is a distinct resource, and a lock on the collection is independent
of a lock on any of its members (separate resources, separate locks).

And to emphasize, a DELETE and a MOVE are modifications to the state
of the collection containing the resource being deleted/moved.  For a
MOVE, it is also a modification to the state of the collection
containing the Destination of the move.  In either case, it is not a
modification to the state of the resource being deleted/moved.

Cheers,
Geoff



   From: "David Motes" <david@pentaventures.com>

   -----Original Message-----
   From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>

   >   From: John Stracke <francis@ecal.com>
   >
   >   For collections, this doesn't work properly with your/Alan's proposal
   >   for static depth locking.  If I'm creating a collection, I do LOCK
   >   (404), MKCOL, LOCK--but this LOCK only locks the resources that are
   >   there now (i.e., none).
   >
   >Your lock on the collection locks the state of that collection, i.e.
   >the bindings.  That means that only someone with the lock can modify
   >the state of that collection, such as adding new bindings to it.
   >
   >   So anybody else is free to come along and add
   >   new resources, and my lock means nothing.
   >
   >Not unless they have the lock.  See above.


     Huh? In your original post about static depth locking you say:

   <GMC>
   Here is (what I consider) to be an extremely sensible proposal from
   Alan Babich (from a few months ago).  He basically says that if you
   are going to do depth locking, it should be static, i.e. it should
   be a lock on the current members of the collection.  If you MOVE
   things into and out of collections (because you have the appropriate
   lock tokens for the appropriate collections), it has no effect on
   the locks on those resources.
   </GMC>


   Lock the CURRENT members of the collection.

   I believe that is what John was commenting on.

   This is giving me a headache :-)


   -David

Received on Friday, 15 October 1999 12:13:37 UTC