Re: Crossserver ops and lock token swapping.

<gs>
> 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?
</gs>
<jlc>
They have to support tokens generated by the other server anyway if they support
locking and cross server bindings.  So what would they do?  They'd do whatever
they'd do for x-server locks.  And what might that be?  Depending on the
operation it might delegate... or the servers would use out of band
communication to cooperate on locking issues.    As for the out of
band-communication, we haven't defined that.  That's not in the scope of the
current WebDAV protocol.

Now of course, I think you're thinking about how a server would support this if
that server doesn't support x-server bindings.  Such a server is very unlikely
to implement support of lock tokens generated on other servers.  So... Yes, the
ability to reissue lock tokens upon MOVE would enable a case that wouldn't
normally be available to this server.  (Note: this problem is specific to
Judy's/ proposal to move locks with moved resources.)  In addition, if we're
serious about this situation, we'd probably want to enhance WebDAV to provide a
way to  specify authentication information for the destination server.  This is
probably a good idea anyway. (Anyone want to start a thread?)

Also note: another approach such a server might take is to not allow the MOVE if
any of the source resources are locked.  Remember... we're talking about a
server that is already limited in its cross server capabilities.  Note
regardless of reissuing lock tokens, no resource with two binding (caveat
omitted) can be moved between this type of servers.  Not supporting cross server
movement of resources that have locks rooted on them would be just another
limitation of these servers.  So what is user of such a server to do?  Well I
suppose they could unlock the source and then MOVE.  Another option is to do a
COPY/DELETE.  I don't think that *requires* any sophistication or cooperation
between servers.
</jlc>

<gs>
I say the MOVE allows the lock token to change, or it just isn't going
to happen.
</gs>
<jlc>
I don't like it, but I'm willing to give that a shot if we don't make it
specific to x-server moves.  No special cases here for x-server.  We'd have to
allow lock token changing on what appears to be a local operation also.  To take
your example... if the same server had both a SQL and file system implementation
running in tandem, it could then change the token.  Of if for some reason it
decided to encode the LOCK URI in the lock token, it could reissue it if the
protected URI changed due to MOVE's or whatever within the same server.

BTW, this example is admittedly poor.  A good implementation is unlikely to
encode this stuff in the lock-token.  And the code that enforces the lock token
probably is implemented earlier/higher in the server than the part that care
about the difference between SQL or filesystem.  This doesn't undermine your
position though.  Just mine.  But I still philosophically don't want to special
case the x-server case within the protocol.

So, I'd prefer not to support reissuing of lock tokens, but if WebDAV is to
support it, let's not make it a special cross-server case.
</jlc>



<gs>
>    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.
</gs>
<jlc>
Works for me too.  But I'm still trying to fully exercise the proposal that Judy
posted.  :-)
</jlc>


<gs>
>       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.
</gs>
<jlc>
I forget if Judith mentioned it in her posting, but as discussed off line, in
her proposal the response could return a new locktoken of the source resource in
the header of the response.   If any other resource changed its locktoken, then
the new lock token could be obtained through lock discovery.  Of course it would
be efficient if the server's response warned the client that some lock tokens
had been reassigned so that the client code would only do lock discovery when
necessary.  Argh... I'm just thinking about that poor client harvesting all the
reissued lock tokens.  I suppose we could enhance the MOVE response to make that
more efficient.

Anyway, my preference is not to reassign lock tokens during MOVE's.  This is
all, "what if".
</jlc>

Received on Friday, 10 September 1999 21:20:34 UTC