RE: Locks and loopback bindings

Jim wrote on 12/06/2004 06:11:01 PM:
> 
> Julian writes:
> 
> > 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.

I fail to understand your concern here.  If a user places a lock on
the root of the resource space, standard semantics apply and the whole
resource tree is locked.  If a user places a lock on a resource that
has a binding path to the root of the resource space, standard semantics
apply and the whole resource tree is locked.  Why is the first OK and
the second a problem that needs to be fixed?

One can make just a good a case that the standard semantics is what
is intended, so I see no compelling case for defining exceptional behavior
here.  In particular, the alternative semantics you describe are more
complex, and likely to be computationally impractical to maintain as
bindings are added and removed under a depth locked resource.

> > 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.

I don't see why this is a problem.

> > 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."

If we decide that the standard semantics should apply to this case,
then I believe that we should not single it out, just to say "the standard
semantics apply here as well as everywhere else".

> > 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.

I'd be interested in the combinatorics/cost of maintaining the semantics
you are suggesting when adding or removing bindings under a depth lock.
In particular, turning an UNBIND/REBIND/BIND into an operation that takes
time proportional to the number of members of the resource would be a
bad thing.
 
> > 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.

Just because a spec makes an operation easier doesn't decrease the 
conflicts
that arise when the spec defining that feature modifies the semantics, and 
the
spec that "makes that feature easier" are not being maintained/released in
lock step.

> * 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).

Same response to "raising more forcefully".  Doesn't change the spec
interconnection problem introduced by defining the semantics of a feature
in a different spec from the one that introduces it.

> * 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.

Good thing that we're working on 2518bis then (:-).

> 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.

I agree.  But I believe the standard semantics should apply in this case,
so I believe no addition to the text is needed for it.

Cheers,
Geoff