Re: Bindings, Locks, and MOVE

On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote:

>    From: ccjason@us.ibm.com
> 
>    <JS>
>    This discussion began with Yaron's comment that saying that "it MUST NOT be
>    possible for a principal other than the lock owner to make a locked resource
>    inaccessible via the URI mapping used to lock the resource" is too strong.
>    It may make sense for write locks as defined in RFC 2518, but may not make
>    sense for other sorts of locks that don't restrict MOVE and DELETE.
>    </JS>
> 
>    I believe that this is not specific to any particular type of locks.  All
>    clients need to insure that they have at the very least a way to unlock
>    the the locks they have created.  I assume that to unlock (a resource), we
>    have to provide a URI of a (the?) resource locked by that lock... so if
>    someone else changes the URI, it's
>    very likely that we're not going to be able to figure out what the new
>    URI is... and will have to leave the lock around until it times out.
> 
> <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.
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.

Regards, Edgar

-- 
Edgar.Schwarz@de.bosch.com ON/EMS1, 07191/13-3382         Niklaus Wirth:
Privat kann jeder soviel C programmieren oder Videos ansehen wie er mag.
Albert Einstein:  Mach es so einfach wie moeglich, aber nicht einfacher.

Received on Friday, 3 September 1999 02:31:05 UTC