- From: <jamsden@us.ibm.com>
- Date: Wed, 22 Sep 1999 22:11:22 -0400
- To: w3c-dist-auth@w3.org
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