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

On Dec 20, 2005, at 11:23 AM, Julian Reschke wrote:

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

You could consider the current draft to hold concrete text.

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

It's simpler for the client -- simpler client logic, fewer special 
cases.  In particular, it's a model that plain RFC2518 clients (clients 
that haven't implemented any of BIND) can understand.

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

Since that's covered in the BIND request, which is not part of RFC2518, 
I didn't see a need to get into that.  DELETE is part of RFC2518 thus 
we have to cover its behavior.

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

I'm not convinced it' s a more expensive implementation.  The best case 
for that argument is that it's a more expensive *server* 
implementation, for those servers which implement BIND.  It seems 
simpler for everybody else.

It matters because of the behavior with clients that are not aware of 
BIND.

Lisa

Received on Tuesday, 20 December 2005 19:36:24 UTC