Re: Locks and loopback bindings

If we can get a rough consensus on the expected behaviour of locks on 
circular binds, I'm all for putting it in the spec. If not, I think the 
spec should remain silent on the issue.

Am 07.12.2004 um 00:11 schrieb Jim Whitehead:

> Julian writes:
>
>> So, for a set of bindings that are part of that cyclic graph,
>> which one is "causing" it?
>
> Ah, now I see what you and Stefan are getting at. The binding 
> "causing" a
> loop can depend on the traversal through the graph.
>
> For a given DAV operation, there is an out, though, in that you have a
> starting node for the operation. Given this, the binding causing a 
> loop is
> one that either:
> A) points to a resource already traversed (child loop)
> or
> B) points to a resource that is both on the path of the starting node, 
> and
> has shorter pathlength than the starting node (parent loop)
>
> (Let's see how this flies -- I have a sneaking suspicion I'm 
> forgetting some
> edge case).
>
>> IMHO it doesn't because it doesn't need to. As far as I can
>> tell, until we say something else, the standard semantics
>> apply (and as far as I can tell, it's clear what they define
>> in this case).
>
> But because of the existence of loopback bindings, and their ability 
> to have
> an operation bleed out to the entire resource space of a server, its 
> not
> clear that the standard semantics should apply here, and hence saying
> nothing is ambiguous.
>
>> As long as a server stops descending into a collection when
>> it detects that it has visited that collection before, there
>> doesn't seem to be an issue.
>
> We agree here. The problem comes when you visit a parent collection of 
> the
> starting point of a Depth infinity lock.
>
>> IMHO deep locks on bind loops are an edge case, in particular
>> if the bind loop includes the namespare root (as in the
>> example we discussed).
>
> So, how do we distinguish between edge cases we should address in the
> specification, and edge cases we shouldn't? Being an "edge case" 
> doesn't
> immediately translate to "don't have to deal with this."
>
>
>> Is there anybody how already supports both or plans to
>> support both and will *not* implement the standard RFC2518
>> deep lock semantics?
>
> I could say that the Catacomb server plans on doing this, though 
> frankly I
> still haven't made up my mind yet.
>
>> BTW, another thing to keep in mind is that you don't need the
>> BIND spec to create bind loops. Once you accept the existence
>> of multiple URIs to the same resource, and the fact that
>> these resources can be collections, a simple MOVE operation
>> can create a BIND loop.
>
> You seem to roughly have the following criteria for whether to include
> language in the bind specification:
>
> * specifically addresses behavior defined in the bind specification
> * is not behavior explicitly defined in another specification
>
> These are reasonable. I feel I've addressed them by noting:
>
> * The ability to create bind loops is made much easier by the 
> existence of
> the BIND and REBIND operations.
>
> * The interaction of bind loops and locking is hence raised far more
> forcefully by the bind specification. Furthermore, there is some 
> difference
> of opinion over what this interaction should be among people who are 
> experts
> in the area (you, me, and Geoff).
>
> * It's not clear that the authors of 2518 clearly knew whether their
> containment model was broadly inclusion-containment-like, or
> referential-containment-like. Certainly the amount of thought we put 
> into
> this particular case was close to zero, and 2518 reflects this.
>
> Since I feel I've made this case pretty well, I'd prefer that we focus 
> our
> attention on the technical issue, that is, developing appropriate 
> language
> for handling this feature interaction. We're writing essays over the
> inclusion of a page of text, tops.
>
> - Jim
>
>

Received on Tuesday, 7 December 2004 07:28:03 UTC