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

Lisa Dusseault wrote:
> 
> 
> 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) We are trying to come up with a paragraph that summarizes lock 
semantics. RFC2518(bis) does not have this.

2) Please point to a piece of text that's not in sync with GULP, in 
particular saying what you think it says about DELETEing "other" 
bindings to a locked resource.

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

How does it affect the client? How do things get simpler for a client? 
Please explain.

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

I don't think that's helpful.

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

I'm still waiting for an example *why* it matters. Just stating that 
some client implementors may find that behavior surprising is hardly a 
technical argument. For instance, when you have multiple URLs for one 
resource, updating URL a may also affect URL b. That's also "surprising" 
for clients that do not expect that.


Best regards, Julian

Received on Tuesday, 20 December 2005 19:58:34 UTC