- From: <ccjason@us.ibm.com>
- Date: Sat, 11 Sep 1999 17:14:31 -0400
- To: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
- cc: w3c-dist-auth@w3.org
<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