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

   <gmc/> I agree with Yaron that we do not want to bite off general
   transactioning support as part of WebDAV.
</jlc> I agree.  I also agree with his implying that NULL LOCKS aren't really a
violation of this design philosophy.


   <yg/> BTW, in so far as what happens when you DELETE a locked resource I
   completely oppose the suggestion that DELETING a resource results in a
   lock-null resource. That is absolutely contrary to the definition of DELETE.
   DELETE deletes the resource not the name. Since the lock is associated with
   the resources deleting a locked resource deletes both the resource and the
   lock.

  <gmc/> If lock were *really* just associated with the resource, I'd be a
  happy camper.  For one thing, it would mean that when multiple URL's
  are mapped to a single resource, you could issue the LOCK against any
  of those URL's and the result would be identical.  Similarly, you could
  later on issue on UNLOCK against any of those URL's and again, the result
  would be identical.

<jlc/> I think if we say that locks are bound to URI's, I'm comfortable with a
null lock resource being left after a delete.  At least optionally.  This can be
very handy and leverages null lock resources well.

<jlc/> OTOH, if we go with a model that locks are bound to resources and that
DELETE deletes bindings, then something has to give. (If not, DELETE may
actually create a lock so that the null resource has a lock and so the original
resource also has a lock at its other bindings.  Hmmm.) I think what has to give
is that null locks go away.  At least for DELETE in this model.

<jlc/> I think Yaron just posted that DELETE deletes resources, not bindings.  I
prefer the "single UNBIND" model of DELETE.   A lot of discussion has already
gone into this.


   <gmc/> I personally believe that the best answer is to fix the LOCK
   semantics so it *really* is just on the resource (and not on the
   name).  Then things are simpler and consistent, even in the case of
   multiple URL mappings to a resource.  Rather than "protecting" a URL
   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.

<jlc/> I agree in principle about that changing to a pure model should be
easier.  (Pure URI or pure resource.)  I'm uneasy though about the mechanism
suggested to find where resources have moved to.  Seems messy.  Less so without
depth locks though.  More analysis later.



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

<jlc/> I'll play along for now. :-)


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

<jlc/> Sounds fine.


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

<jlc/> Sounds fine given the model.  I do think locking a collection is a rather
fat approach but I still agree with your point.

Received on Friday, 24 September 1999 19:08:14 UTC