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

   From: Edgar Schwarz <Edgar.Schwarz@de.bosch.com>

   > <gmc/> But I have seen various arguments in the past that a LOCK should
   > also protect the URL to resource mapping.

   <es/> For my part I was just concerned that the locker should be able 
   to find his locked resource after a MOVE.

Yes, I believe that is the essential functionality to be provided, in addition
to the lock on the state of the resource.

   <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!

   > <gmc/> So there are really multiple threads here:
   > - Should locking be on a resource or also/instead on a URL-to-resource
   >   mapping?  (we know what it is now, but what *should* it be)
   > * I vote "on a resource".
   > - Does a DELETE delete all bindings to a resource, or just the one
   > specified in the request-URL.
   > * I vote "just the one named by the request-URL".
   > - Should a DELETE delete a LOCK?
   > * I vote, "no".  A DELETE modifies the state of the collection containing
   >   the binding, not that of the resource.  In particular, all other
   >   mappings to that resource will continue to exist and display the
   >   LOCK'ed semantics.  If you want to prevent a DELETE, you put the
   >   LOCK on the collection whose state is being modified.

   <es/> Agreement on all points. The last couple of days I thought that
   already too much energy was spent with this topic.  This proposal
   seems to be as simple as possible, but not simpler.

<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.

Cheers,
Geoff

Received on Friday, 24 September 1999 08:59:31 UTC