Locks and loopback bindings

> I guess this explains the confusion. The operation that 
> you're showing here keeps the binding name (CollZ), but 
> changes the resource to which it refers (from C1 to C2). This 
> is neither a MOVE nor a REBIND operation.
> 

Ah! Thanks for figuring this out. So, REBIND really moves the head of the
binding from one place to another. I was assuming it moved the tail from one
place to another.

I'll have to rethink the desired example.

> The other obviously open question was whether bind loops need 
> special treatment regarding depth:infinity locks. I wasn't 
> under the impression they do. Is there a specific problem 
> that needs to be solved?

Well, there are two issues. One is the handling of If headers for loopback
bindings. The other is the semantics of the lock operation in the presence
of loopback bindings. I think the handling of If headers is relatively
straightforward. The semantics of locking are not.

Consider the following collection hierarchy:

+------------------+
| Root Collection  |
|  bindings:       |<---------------------+
|  CollW           |                      |
+------------------+                      |
     |                                    |
     |                                    |
     |                                    |
+-------------------------------+         |
| Collection C1                 |         |
| bindings:                     |         |
| CollX               CollY     |         |
+-------------------------------+         |
     |                  |                 |
     |                  |  (creates loop) |
     |                  |                 |
+-----------------+  +------------------+ |
| Collection C2   |  | Collection C3    | |
| bindings:       |  | bindings:        | |
|  {none}         |  | y.gif     CollZ  | |
+-----------------+  +------------------+ |
                       |            |     |
                       |            +-----+
                       |
                   +---------------------------+
                   | Resource R2               |
                   +---------------------------+

What is the outcome of an exclusive LOCK, depth infinity, submitted to
/CollW/CollY/ ?

Seems to me, the desired outcome is that only C3 and R2 are locked. 

However, if you read 2518, section 8.10.4 (Depth and Locking), it says:

"If the Depth header is set to infinity then the resoruce specified in the
Request-URI along with all its internal members, all the way down the
hierarchy, are to be locked." 

In the binding specification, we define an Internal Member URI as 

"The URI that identifies an internal member of a collection, and that
consists of the URI for the collection, followed by a slash character ('/'),
followed by the path segment of the binding for that internal member." 

So, following these two definitions, one would interpret CollZ as an
internal member URI, and then have the lock request apply to it, in this
case locking the root collection, and all of its internal members, etc. What
happens next is unclear. Either the lock fails (because /CollW/CollY/ is
already locked), or the entire URL hierarchy on the server is added to the
lock. 

In both cases, this seems like undesirable semantics. Lock really should
ignore any loopback binding. While loopback bindings could theoretically
have existed in the 2518 world, it really is only the introduction of the
BIND specification that starts raising these issues with any urgency.

- Jim

Received on Friday, 3 December 2004 20:23:10 UTC