RE: Locks and loopback bindings

Geoff Clemm writes:

> Bind loops are fine.  Depth:infinity applied to bind loops is what 
> causes the problem.  As Julian indicates, how a particular server decides 
> to handle Depth:infinity locks in the presence of bind loops (for those 
> very rare servers, if any, that actually support this) will be very 
> idiosyncratic to that particular server.

My assertion is the semantics of Depth infinity locks and loopback bindings
will be very consistent -- servers will ignore loopback edges when computing
the closure of the containment graph of a collection for the purpose of
locking.  This is a very consistent semantics, one that is easy to specify,
and easy to understand. 

Furthermore, I also assert that there is no reasonable scenario under which
a server would ever want to follow the loopback bindings when computing
Depth infinity closure. Given this, we would be acting responsibly as
specification writers to clarify the semantics of this situation, and to
close off undesirable semantics.

> We need to maintain 
> a discrete silence here, since we really can't predict what a server 
> will need to do, or be able to do, in a case like this.  But this is 
> a very unlikely edge case, and therefore I believe doesn't merit any 
> spec space devoted to it.

I don't think we can reasonably predict how many servers will implement both
loopback bindings and depth locks. 

We do know there is a feature interaction issue here. We also have
sufficient experience to be able to analytically determine that allowing
locks to follow loopback bindings can cause an operation to have unexpected
scope of impact from a user-directing-a-client perspective. We need some
SHOULD-level guidance for servers that decide to support both depth locks
and loopback bindings. (I personally think it could be MUST-level, but would
be happy with at least SHOULD).

It is negligent to duck this feature interaction. All servers that currently
implement depth locks and plan on implementing the BIND specification will
need to make decisions about how to handle this interaction, whether by
disallowing loopback bindings, depth locks of loopbacked collectioned, etc.
At the very least we need an implementation note outlining Geoff's options
so implementors can make reasoned decisions about how to duck the issue.
Even better would be supplementing this with feedback on how to do a good
job of providing both features simultaneously.

- Jim

Received on Monday, 6 December 2004 17:22:10 UTC