- From: Greg Stein <gstein@lyra.org>
- Date: Wed, 08 Sep 1999 13:08:03 -0700
- To: "Slein, Judith A" <JSlein@crt.xerox.com>
- CC: w3c-dist-auth@w3.org
Slein, Judith A wrote: > > The intention is that if a resource is copied or moved into a tree that is > locked, the lock on the tree remains in force. > > We didn't discuss the case where you are doing a MOVE, and the resource > being moved is locked, and it is being moved into a collection that is > locked. The lock on the collection will certainly stay in force, but we > need to decide whether the lock on the resource being MOVEd will be lost or > whether the MOVE will fail. I guess my own opinion is that the MOVE should > fail, since that maintains a consistent position that the state of a MOVEd > resource should be unaffected by the move; if its lock state would have to > be changed, the move should fail. There is a third case: allow the move. How about this: allow the MOVE, the resource then falls under the Destination lock, the source is now in a lock-null state. Therefore, the user does *not* lose any locks, the MOVE is completed, and this scenario actually provides a way to do a "safe" MOVE. If the user could not lock both ends, then you have a race condition. Further, making the user lock the source "one level up" so that the lock wouldn't move with the resource just feels like a hack. If you are MOVEing a collection and there is a lock on one of the collection members, then the move should fail if there is an incompatible lock (e.g. exclusive and not the same lock) at the destination. Cheers, -g -- Greg Stein, http://www.lyra.org/
Received on Wednesday, 8 September 1999 16:17:37 UTC