RE: DELETE leaving a lock-null resource; was LOCK Scenarios

Geoff Clemm and Edgar Schwarz write:
>    <gmc/> to resource mapping, I'd propose that a locked resource
> be allowed to
>    MOVE (this is just a change to the state of the parent collection, not
>    to the state of the resource being moved), but that an attempt to
>    access the MOVE'd resource with that lock just returns a 302 indicating
>    where it has MOVE'd to.
>
>    <es/> This would give me what I wanted. I even could imagine that it
>    is enough that only a access with the lock token MUST get the new
>    location.  For all others it's just gone, like other resources which
>    are moved.  So a server could just remember lock tokens together with
>    old and new URLs and keep this data until it is accessed by the locker
>    or the lock expires.
>
> <gmc/> Ah yes, *much* better than the 302's, and provides better
> compatibility with clients written against the existing locking
> protocol.  Great idea, Edgar!

I'm not convinced this will work, since it only handles the case where the
resource is moved just once.  What happens if a resource is locked, then
moved, and moved again?  How many steps is the server required to remember?

> <gmc/> I've been agonizing for months over trying to make the existing
> locking protocol work unmodified in the presence of multiple bindings
> and versioning.  There are massive numbers of edge cases and things
> that just plain don't work.  If you just say that a lock is on a
> resource, and then use Edgar's proposal that a lock token combined
> with the original URL guarantee access to that resource, then multiple
> bindings and versioning semantics interacts can be combined with
> locking in a manageable fashion.
>
> I'll make a pass through the current version of 2518 to identify the
> sections that would need to be modified, and will run this against
> Judy's list of use cases for locking in the presence of multiple
> bindings, to see how the details play out.

I'm looking forward to this.

- Jim

Received on Friday, 24 September 1999 17:27:59 UTC