Re: Bindings, Locks, and MOVE

The only rationale that has been presented for having locks be lost after a
MOVE is the case of cross-server MOVEs.  The source server and destination
server may use different URI schemes for lock tokens, so that the
destination server may be unwilling to keep the same lock token for the
MOVEd resource.

We can make support for cross-server MOVEs of locked resources optional, and
allow the destination server to replace the lock token with a different lock
token.  We'll provide a response header for it to use to report the new lock
token.

<jra>
This is not the only rational for loosing locks. It is possible that the
resource will be moved from one repository to another in the same WebDAV server,
or from one pyysical drive to another. That is, the actual server implementation
may change depending on the source and/or destination resources and/or the URLs
used to access them. DAV4J supports multiple repository managers in the same
server so clients can access resources from them without being aware of how the
resources are actually stored.

Unfortunately, MOVE is sometimes the same resource in a new location, and
sometimes a new resource. Cross server MOVEs are almost certainly new resources.
Depending on server implementations, MOVE within the same server might be too. I
don't think the semantics of MOVE can depend on whether the resource is actually
copied or not. Note that it is also possible that the supported live properties
may change from location to location in the same server as well as across
servers for the same reasons. If we want to control this behavior, we have to
have two moves, one that copies and one that renames. Then servers can fail the
operations if they can't support them.

Finally, much of the justification for protocol changes is based on "user
expectation". I would submit that the COPY/MOVE/LOCKing semantics are getting so
complicated that most users will not be able to determine if their expectation
is being meant or not. I continue to believe that MOVE and COPY need to be
treated as a server convenience to reduce client/server interaction, and their
semantics should be defined completely in terms of more primitive methods like
GET/PROPFIND and PUT/PROPPATCH with or without DELETE. If this can't be done,
then there might be something wrong with these methods, not COPY and MOVE.
</jra>

Received on Wednesday, 22 September 1999 22:33:05 UTC