- From: Greg Stein <gstein@lyra.org>
- Date: Fri, 10 Sep 1999 14:44:40 -0700
- To: ccjason@us.ibm.com
- CC: w3c-dist-auth@w3.org
ccjason@us.ibm.com wrote: >... > I'd like to propose that moving a lock across servers not change the lock token > for a lock on that moved resource.. The reason I say this is because we are > claiming in the proposal that locks are on resources... not bindings or URI's. This is rather neat philosophically/academically, but from a pragmatic standpoint, I don't think it really holds water. Let's just take a simple example of a resource being moved from a filesystem into a database. The filesystem prefers scheme X to represent the locks. The database prefers Y. Sure, they could both use opaquelocktokens, but they aren't -- they're each using a scheme to optimize their behavior. Now what are you going to do? I say the MOVE allows the lock token to change, or it just isn't going to happen. > 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 Again: neat philosophy. Go implement this and I'll buy it. >... > move them. Can we actually expect unsophisticated servers to actually support > locks generated by other servers? So this suggests... Nope. But that was probably a rhetorical question :-) > 1) MOVE does not move locks from source to destination in any sense. (But > this breaks model of resource is what is locked.) Works for me. [although, as I stated in reply to Judy's initial proposal: I'm also fine with moving the lock. I think it isn't making as much sense (to me) to move it, though. more below] > or > 2) We let the destination reassign lock tokens. (Is this situation important > enough to take this approach and complicate the spec? And wouldn't they still > face authentication issues?) I prefer this option. Why not just allow the MOVE to return a Lock-Token header? The Lock-Token header would specify the lock that the (moved) resources now fall under at the destination. There is an issue, though: what of the old locktoken? Did it get moved (and changed) or did it remain? Hrm. This isn't an issue, though, if we state that it always remains (yes, this is different than Judy's latest proposal; it also follows my suggestion about it remaining and establishing a locknull resource). If the lock remains, then client can always know what happens -- the source lock remains, the resource now falls under the lock specified by the returned Lock-Token. > or > 3) MOVE wouldn't be allowed between these these servers. The client would > have to use > DELETE/COPY/DELETE. (Keeps protocol simple. Probably is good enough for those > with cheap servers.) This is *always* an option. A server can always return Bad Gateway if it chooses not to do a move. > > Thoughts? > > Further thoughts on cross server. As some have pointed out, right now the spec > is nowhere near close enough to actually enable two independently developed > servers to do cross server operations besides possibly COPY. Things like > cooperative authentication and lock and binding protocols are are needed. And > we need to specify that lock tokens be standardized. (We might want to address > this now rather than retrofit this later.) (Judith pointed this out.) So are > we agree'ing that WebDAV is to be cross server friendly/compatible... but not > enabling? (Is that what Yaron was trying to say? :-)) I believe Yaron was trying to say that we should not be considering server-to-server communication. The WebDAV charter explicitly states that this is not in scope. As a result, any portion of the specification that are necessary *only* for server-server communication should be axed. If you can argue a DAV client would use it, then it can stay :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Received on Friday, 10 September 1999 17:53:14 UTC