RE: Locks and loopback bindings

Geoff wrote on 12/06/2004 11:45:00 PM:

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

I retract my concern about the combinatorics, since I believe a way to 
phrase Jim's proposal is that:

"Suppose there is a depth lock, and:
- there is one path to that resource is protected by that lock but
the resource is not locked by that lock (because the resource is
a parent of the locked resource along the path protected by the URL), and
- there is another path to that resource that would lock the resource
by that lock (because of a binding loop to that resource),
then the semantics of the non-locking path applies
(i.e. the path to the resource is protected by that lock
but the resource is not locked by that lock).

It is a little more complicated than this, because you have to make
clear that the depth recursion is stopped at this point as well,
but since a server must maintain both the protected and locked 
information,
computing Jim's proposed semantics should be not much worse than computing
information that is already required.

But with all that said, I do not agree that this is the right semantics
for this case, but rather believe that the default semantics is both 
simpler
and more likely to be what the client had in mind for the depth lock.

And if there is no consensus about what the semantics should be in this
case, that is another reason to avoid saying anything about it in the
binding spec.

Cheers,
Geoff