Subject: Re: resourcetype locknull

From: "David Motes" <[email-masked]>
Date: Fri, 15 Oct 1999 10:27:18 -0400

-----Original Message-----
From: Geoffrey M. Clemm <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Friday, October 15, 1999 10:26 AM
Subject: Re: resourcetype locknull

>   From: John Stracke <[email-masked]>
>
>   "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.

  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

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 15 Oct 1999 12:13:35 -0400

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" <[email-masked]>

   -----Original Message-----

   <GMC>

   -David

---

From: <[email-masked]>
Date: Fri, 15 Oct 1999 09:47:16 -0700

Uh, something has been taken out of context.

In Alan Babich's proposal (which I favor a LOT), the depth-0 exclusive lock
on the collection arranges that only the lock holder can add or delete
members.  Even with a depth-1 exclusive lock (which prevents alteration of
existing immediate members by anyone but the lock holder) there is no
problem about new members.  The lock holder creates them with an exclusive
lock and then inserts them in the exclusively-locked collection.  This
provides more than one lock to remove ultimately, but no one said this was
effortless.  (A multi-lock unlock-any-of-these operation would be handy and
a boon to clients without doing much to server's in Alan's
simply-deterministic unlock model.)

If you look at the combinatorial complexity and housekeeping requirements, I
say this will be an easy winner so long as depth locking is important.  The
fact that you can explain this simple model -- and people can still misread
it -- says a lot about what you are saddled with in 2518.  It takes
something to implement the Babich model without literally implementing the
invariants of Alan's proposal, and that tells you something about 2518's
current model too.  I'd say you win simply on the reduced complexity of
validation and regression confirmation of an implementation.  For me, being
able to explain it and understand its deterministic behavior under all
conditions is the key element.  (Yes, I am treating LOCK NULL as orthogonal
to this model.)

-- Dennis

Dennis E. Hamilton
- - - - - - - - - - - - -
mailto:[email-masked]
tel: +1-206-779-9430 (gsm)
fax: +1-425-793-0283
http://www.infonuovo.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of David Motes
Sent: Friday, 15 October 1999 07:27
To: Geoffrey M. Clemm
Cc: [email-masked]
Subject: Re: resourcetype locknull

-----Original Message-----
From: Geoffrey M. Clemm <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Friday, October 15, 1999 10:26 AM
Subject: Re: resourcetype locknull

running.

<GMC>

-David