Re: resourcetype locknull

   From: John Stracke <francis@ecal.com>

   "Geoffrey M. Clemm" wrote:

   >    - return a 404 if there is no resource to LOCK,
   >    - let the client create a "null" instance of what it wants there,
   >    - then the client locks that null instance and it is off and running.

   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.

   For collections that are
   meant to model compound documents or some such, where the entire state
   of the collection needs to be treated as a unit, this is a Bad Thing.

As long as you partition the compound object clearly into disjoint
pieces, and provide a mechanism for locking each of those pieces
(including the pieces that glue the other pieces together, i.e. the
collections!), then you can effectively treat it as a unit by locking
"every piece".  The problem with the current state of locking in 2518
is that the various locks overlap in various complex ways, making the
interaction between locks hard for clients to predict and hard for
servers to implement.  But I think that we can adjust the protocol to
remove this locking overlap in a way that makes it largely consistent
with the existing clients and servers.

Cheers,
Geoff

Received on Friday, 15 October 1999 10:25:32 UTC