Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings

On Dec 20, 2005, at 10:50 AM, Julian Reschke wrote:

>
> LD> One could imagine the lock applying to the resource and to all its
> LD> bindings, considering  the bindings to be part of the state of the
> LD> resource.  If I recall, I think this is the model I'd always 
> assumed
> LD> until GULP.  With this model, if A and B are bindings to a 
> resource,
> LD> and a LOCK token to A is successful, then for the duration of the 
> lock
> LD> the token is required to change either A or B.
>
>> It's actually very similar to the model proposed in GULP.  In that 
>> model, the LOCK covers one binding as well as the resource.  The GULP 
>> model does not imply that the locked binding is part of the state of 
>> the resource either.  What a lock covers is a separate concept from 
>> what a resource state includes.

You're right, I used language in a sloppy way in describing the model.  
Anyway, to update my language, I don't see why the model for a LOCK 
can't cover more than only the binding that was locked and the resource 
(and its state) itself.  We should be picking a model that results in 
desirable behaviors.

>
> Well, it's not completely separate because if affects how Depth 0 
> locks in collections behave.
>
> Anyway, I don't think we'll make any progress unless you tell us 
> exactly which part of GULP you're unhappy with, and how you propose to 
> change it.

I'm unhappy with the consequence of the GULP model that a DELETE of a 
binding to a locked resource may or may not work depending on whether 
that binding was the one locked.  I propose to change it by requiring 
that a DELETE of a binding to a locked resource needs a lock token.

Lisa

Received on Tuesday, 20 December 2005 19:09:33 UTC