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 10:37:41 UTC