Re: Crossserver ops and lock token swapping.

   <jc/> The reason I say this
   is because we are claiming in the proposal that locks are on
   resources... not bindings or URI's.  Well, a MOVE operation is
   basically just a rebinding and in that sense, the resource itself has
   not moved.  MOVE just changes some of the URI's at which resources are
   accessable.  In this case the resource(s) is now accessable via a URI
   on another server.  (Note: It may still be accessable at the source
   server via another URI.)  In order to achieve this, we implicitly
   require (except for special cases) that server pairs cooperate on
   bindings... and therefore locks since a locked resource can be
   accessed via a URI on either machine.

  <gmc/>  I agree with all this, except for the "except for special cases".
  What did you have in mind here?  Either the server pairs cooperate on
  bindings so that bindings semantics is maintained, or they must fail
  the BIND or MOVE request that would have created the cross server binding.

<jlc/>I don't remember what I meant before.  I'm guessing that I was thinking
of the limited situation that I outlined in my note to Greg.  The situation
where there are no locks on the source and only single bindings.  I think
we couldn't protest very vigorously if in special cases like this,
servers (that might not even support bindings) tried to carry out the move
using PUT/PROPPATCH/DELETE.



   <jc>
   These are really simple servers with simple
   mappings.  One mapping per resource.  But one wants to move resources
   between these servers.  Nothing fancy.  Just move them.  Can we
   actually expect unsophisticated servers to actually support locks
   generated by other servers?  So this suggests...

   1) MOVE does not move locks from source to destination in any sense.
   (But this breaks model of resource is what is locked.) or

  <gmc/> I agree.  Unless we want to define two different MOVE
  protocols, the protocol has to make sense not only for simple servers,
  but also servers that do support multiple bindings to a resource.  And
  deleting the locks from the source of the copy does not work if there
  are multiple bindings to a resource that still expect it to be locked.

<jlc/>I'm glad you agree, but I'm not sure with what you are agreeing.
Let me guess that you are agreeing with the, "but this breaks...", so
you are disagreeing with a special case that says in some cases locks
don't move with the resource.  -- Or perhaps you're agreeing that locks
shouldn't move with the resource at all?  (IOW, rejecting "Judith's"
proposal that MOVE's move locks.)  -- Sorry, I should have phrased
these options more concisely and omitted my own commentary from them.



   <yg/> While it is true that we can hack up the protocol to make it support
   allowing the lock token to be changed on a request by request basis this is
   an abysmally bad idea.

   <gs/> Excellent point! I agree with you here. That leads me to believe that
   locks MUST NOT move with the resource since the Destination may not
   support the transfer of the locktoken (heck, what happens if the
   Destination doesn't support locking!).

  <gmc/> The alternative conclusion is that unless the server can maintain
  the lock token, it must fail the MOVE request.  I think this is a more
  scalable/extensible approach than defining special behavior for the
  MOVE with respect to various resource behavior (such as locks and bindings).

<jlc/> We've already explored the world without lock movements on MOVE, so let's
continue exploring based on the variant of Judith's proposal that Geoff just
suggested.  That is, locks remain tied to resources, lock tokens never are
reassigned, if a server can't support this semantic for a given request, it must
reject the request.


   <johns/> It occurs to me that the biggest reason you'd want to MOVE the
   lock is because you want to keep control over the resource in the new
   location.  Couldn't you do that by locking the destination and then
   MOVEing the resource?

  <gmc/> Good point.  I may have to withdraw my objection to the null-resource
  lock, since only the null-resource lock survives a MOVE.

<jlc/> Geoff, what is it that you are withdrawing?  Please clarify.

Received on Saturday, 11 September 1999 17:07:38 UTC