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

Lisa Dusseault wrote:
> 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.

Yes, that's possible.

>> 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.

I still don't see concrete text, but anyway...

1) The cost of locking a resource with multiple bindings will be 
significantly higher.

2) I don't see any gain to a client. The purpose of a lock is that while 
the resource is locked the client is protected from others moving away 
the resource, or modifying it's lockable state. Just protecting the 
binding that was locked achieves exactly that.

3) Multiple bindings to a resource cause the server behaviour to become 
more complex, yes. But the change you suggest doesn't help here; for 
instance it would mean that a client (without the lock token) is allowed 
to add a new binding to a locked resource, but not to remove it.

As long as the model describes the semantics in RFC2518, and a client 
gets what it wants, I don't see any reason for coming up with a more 
complex model.

So the summary is... Why does it matter, and how does that justify a 
more expensive implementation?


Best regards, Julian

Received on Tuesday, 20 December 2005 19:25:41 UTC