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

Edgar,
<gmc> Since the server needs to deal with this in case the client just
neglects to remove the lock, and if having another client MOVE your
locked resource is a rare occurrence (which I believe it is), then
this does not seem to be especially problematical.
</gmc>
<edgar>
Would it be possible to say:
  If a locked resource is moved the server SHOULD create a indirect
  reference resource which should exist for some sensible time.

Yes I know, it's complicating the server :-)
I imagine the above happening perhaps when somebody is reorganizing
a directory structure and deep in the collections there are some
locked resources.
So the lock owner at least has a decent chance to find out where his
resource has gone to.
</edgar>
<jlc>
I believe you're proposing an alternative to protecting a lock URI...

I don't think the server can create the indirect reference *during* the MOVE
since
(1) The now null resource URI may not have a parent after the move if the moved
resource was a grandfather collection above.  I think we require that even
indirect resource have a parent.
(2) The client that requested the MOVE might not be the owner of the lock.  So
telling the mover, doesn't really help the owner of the lock.  I assume the
owner of the lock is the entity most interested in knowing it moved.

A similar approach to what you've suggested might be to provide a URI at the
time the lock is created.  I know that Geoff has one argument against it lined
up already.  :-)  I still think it's worth discussing though.
</jlc>

Received on Thursday, 9 September 1999 22:30:28 UTC