W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1999

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

From: <ccjason@us.ibm.com>
Date: Thu, 9 Sep 1999 22:37:51 -0400
To: Edgar Schwarz <Edgar.Schwarz@de.bosch.com>, w3c-dist-auth@w3.org
Message-ID: <852567E8.000DC2DC.00@D51MTA07.pok.ibm.com>


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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:51 GMT