RE: resourcetype locknull

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:infonuovo@email.com
tel: +1-206-779-9430 (gsm)
fax: +1-425-793-0283
http://www.infonuovo.com

-----Original Message-----
From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of David Motes
Sent: Friday, 15 October 1999 07:27
To: Geoffrey M. Clemm
Cc: w3c-dist-auth@w3.org
Subject: Re: resourcetype locknull



-----Original Message-----
From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
To: francis@ecal.com <francis@ecal.com>
Cc: w3c-dist-auth@w3.org <w3c-dist-auth@w3.org>
Date: Friday, October 15, 1999 10:26 AM
Subject: 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.


  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:53:30 UTC