Re: Crossserver ops and lock token swapping.

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