Protected URI's wes: Bindings, Locks, and MOVE

Okay, a bunch of people have spoken up to say that the lock URI of a write lock
MUST be protected.    The emphasis here is on "MUST".   I tend to agree, but
I'll be a devils advocate...

1)  In the recent proposal by the AdvColl folks (including myself) that Judith
posted, we also proposed that locks at the source move to the destination when a
MOVE occurs?

Are we prepared to say that the protected URI also moves?


2)  Okay, this proposal has also tried to promote the model that it is the
resource that holds the lock... not the URI or something else.  OTOH, you all
have probably heard me speak of a protecte *URI*.   It does seem odd that we say
that it's a resource that is locked, but that it's a URI that is protected.
Here's thinking of why it's a URI.
Now let's consider the case where the lock is rooted at a resource that has two
bindings to it.

/a/b
  and
/x/y


both refer to the same resource, but /a/ and /x/ are different resources.  (We
have two bindings to the resource at /a/b.)

Now let's lock /a/b.  /a/b is protected, but is /x/y?  Most of us would say no
since unbinding /x/ or /x/y wouldn't interfere with what resource is at /a/b.
That might strike us as odd because we've said that the lock is rooted at a
*resource*... but only some mappings to the resource are protected.    We might
even be tempted to say that the protection is rooted at the *binding* since
breaking the binding /a/b nor matter what mapping is used, will change what
resource is at /a/b.  Well...

Let's have

/a/b
   and
/m/n/b

Where /a/ and /n/ are the same resource.  And let's lock /a/b.   Now /a/b should
be protected.   But is /c/d/b protected?  It's the same resource... and they
share the same binding?  On the otherhand, I think everyone would agree that
despite the lock, anyone would be allowed to UNBIND (DELETE in our current
vocab)  /m/ and /m/n/.   Therefore /m/n/b is not protected despite that resource
only having one binding.   This suggests that the protection is rooted a URI,
not a resource (and not a binding).

Admittedly that's just saying that it is the URI -> resource mapping that is
protected... which seems much more benign.



Now we've said it's a URI mapping that is protected.  Here's a contrived santity
check...

/a/b/c/d   is locked.

/m/c/d also exists.

/a/, /a/b/  /a/b/c/, /m/, /m/c/  are all distinct resources.  The only resource
here with mutliple bindings is the resource at /a/b/c/d and /m/c/d..

Now an outside entity that doesn't have the lock does a   BIND /m/    to dest
/a/b/.

Do we allow the BIND?  Note: the parentage of the protected resource has
changed... but it's final mapping has not.

Can a server allow it?  Should it allow it?  MUST it allow it?  Note: if we say
MUST, that means a server has a bit more work to do.  It has to create a model
of the final state and determine if any mappings change.  Perhaps not  *much*
more work... but definitely *more*.

So is it okay with everyone to say that although it's a resource that's locked,
it's its lockURI mapping that is protected?  Or is this difference disturbing?


3) I have another set of rhetorical questions regarding reasigning a protected
URI to a lock on a MOVE, but first I'd like to hear comments about what I've
said above.   (It's also past my bed time. :-))



------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com

Received on Friday, 10 September 1999 01:04:48 UTC