Re: Locks and loopback bindings

May I ask what the definition of a "loopback binding" is and how it 
differs from other bindings?

In my concept, all bindings are created equal and which binding "loops 
back" to where depends on the path you take when traversing collection 
"trees", as I see it. From mathematical perspective, bindings transform 
the well known *tree* into a directed graph. Some servers will require 
acyclic graphs while others will allow cycles.

The set of deep-locked nodes is the set of nodes reachable from the 
starting point. We could provide an algorithm for server implementors, 
and even more important for clients, on how to find this set and not 
get lost in possible cycles.

Stefan

Am 06.12.2004 um 18:21 schrieb Jim Whitehead:

>
> 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:41:45 UTC