Re: GULP (version 5)

On Thursday, 10/10/2002 at 04:59 AST, "Clemm, Geoff" wrote:
> Here is a new GULP, that tries to address the points raised in the 
> mailing list (i.e. UNLOCK, lock state clarification, submission of 
> lock tokens). 
> 
> ************************** 
> 
> Grand Unified Lock Proposal (V5) 
> 
> - A lock is either direct or indirect. 
> 
> - A LOCK request places a direct lock on the resource identified by 
>   the request-URL.  The "lock-root" of the new lock is the request-URL. 
> 
> - If a collection has a direct depth:infinity lock with token X, all 

Actually it doesn't matter if it's direct or not in this sentence.... or 
is "members" a recursive term?

>   members of that collection (other than the collection itself) will 
>   have an indirect depth:infinity lock with token X.  In particular, 
>   if a binding to a resource is added to a collection with a 
>   depth:infinity lock with token X, and if the resource does not have 
>   a lock with token X, then an indirect lock with token X is added to 
>   the resource.  Conversely, if a resource has an indirect lock with 
>   token X, and if the result of removing a binding to the resource is 
>   that the resource is no longer a member of the collection with the 
>   direct lock with token X, then the lock with token X is removed from 
>   the resource. 

Again, it doesn't need to be direct at the parent, just the ancestor
unless "members" is recursive.



> - An UNLOCK request removes all locks (both direct and indirect) that 
>   have the lock token specified in the Lock-Token header of the request. 

>   The request-URL of the request MUST identify a resource that 
>   has a lock (either direct or indirect) with the specified lock token. 

I am uncomfortable refering to multiple locks.  I've always thought of it
as one lock that affects multiple resources.   I'm also uncomfortable 
saying 
a resource *has* as lock as opposed to saying it *is* locked.
But I have to admit that how you're saying it so far 
is very easy to understand.


> - A lock token is "submitted" in a request when it appears in an If 
>   header tagged-list whose tag is the lock-root of the lock. 
> 
> - If a request would modify the content or dead properties of a locked 
>   resource, or would modify the bindings of a locked collection, the 
>   request MUST fail unless the lock-token for that lock is submitted in 
>   the request. 
> 
> - If a request causes a resource with a direct lock to no longer be 
>   mapped to the lock-root of that lock, then the request MUST 
>   fail unless the lock-token for that lock is submitted in the 
>   request.  If the request succeeds, then that lock MUST have been 
>  removed from that resource by that request. 
> 
> - If a request would cause two different exclusive locks to appear on 
>   the same resource, the request MUST fail. 
> 
> ************************** 
> 
Good stuff. 

Do you want to say what happens if you lock an unmapped
URL?

 That leaves the issue of how much of the If header is evaluated.
I'll start a seperate thread on that as Geoff requested.

------------------------------------------
Phone: 914-784-7569

Received on Thursday, 10 October 2002 21:07:59 UTC