Re: What is actually locked?

Lisa Dusseault wrote:

> Patrik asked: "Now, Lisa, you seem to either not agree with this view, 
> or that the document doesn't specify this clearly enough. Can you (Lisa) 
> clarify?"
> 
> Yes, I've had various discussions where it seemed that if one binding to a
> resource was locked then other bindings also had to appear locked, and
> I've had other discussions where it seemed the other way.  Reading the
> specification might lead a person to one conclusion, but it might lead them
> to the other conclusion.  By now I've read the spec many times, but I 
> recently
> reread it carefully and tried to do so with an open mind, and I found 
> that it
> is unclear -- it is difficult to integrate statements from different 
> sections of
> the draft to come to a conclusion.  It's not merely that this is more 
> work for
> the reader of the spec, but it is also prone to parsing and integration 
> errors.

Well, in fact the BIND spec says almost nothing about locks; so I'm not 
sure where you see the ambiguity. BIND doesn't in any way change the 
locking model defined in RFC2518; and that locking model is about 
*resources* being locked. So yes, if a resource is locked through one of 
it's bindings, the lock will be visible (and active) for all other 
bindings as well -- again, that's a basic property of the model; 
additional bindings give you additional access paths to a single 
resource, but you're always manipulating / discovering the resource itself.

If you can point to a section in the BIND spec that suggests otherwise, 
*please* do so.

> Some of the details resulting from the lock model are even more definitely
> unclear.  For example, can a client use UNLOCK on a binding that isn't the
> one that was locked?  If not, what's the error?  The spec must say whether
> a server MUST support UNLOCK on all bindings to a locked resource.

The spec says in it's introduction that additional bindings just add 
additional access paths to the same resource, and that HTTP methods 
access the resource itself. Thus the access path doesn't matter, and 
UNLOCK must work on each of the bindings to the resource.

> It's my belief that interoperability will suffer from the readability 
> problems
> in this specification.

I think the introduction section is very clear about all of this:

"A method is addressed to a URI, and the server follows the mapping from 
that URI to a resource, applying the method to that resource."

What else do we need to say here?

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 5 April 2004 16:22:53 UTC