- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Fri, 29 Aug 1997 18:37:45 -0400
- To: "'Dylan Barrell'" <dbarrell@opentext.ch>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
Actually, the present specification does address the interactions of LOCK, COPY, MOVE, and DELETE. Section 5.2.4, Interaction With Other Methods, currently states: 5.2.4 Interaction with other Methods Only two methods, MOVE and DELETE, have side effects which involve locks. When a resource is moved, its lock SHOULD be moved with it. However this may not always be possible and there is currently no proposal to create a header which would specify that the lock request should fail if the resource's locks can not be maintained. A COPY MUST NOT copy any locks on the source resource over to the destination resource. Deleting a resource MUST remove all locks on the resource. There has been some discussion concerning whether a lock should remain the same after a move (i.e., after the move you have the same lock on the same resource, only there is a new name for the resource). My view is that since a move just renames the resource, the lock should still exist after the move. However, this does disagree with the definition of move as a copy followed by a delete of the source, since copy should definitely not duplicate the lock. My solution is to fudge this issue, and state that a move is a copy followed by a delete, except that the lock is transferred intact from the source to the destination. While this gets the expected functionality (the lock follows the resource), it does create a certain inelegance in the definition of MOVE. Also, where did you look for definitions of interactions between locks and other methods -- perhaps this section of the spec. should be located in a different part of the spec. (perhaps divided up and associated with COPY, MOVE, and DELETE?) - Jim On Thursday, August 28, 1997 5:30 PM, Dylan Barrell [SMTP:dbarrell@opentext.ch] wrote: > There seems to be a bit of a hole in the draft in its current form with regard to locks and reservations which needs to be filled. We need to specify - either in the requirements document or in the spec - what happens to locks and reservations when a resource or collection of resources is copied and/or moved. The issue becomes problematic when you consider that the current definition of MOVE is a COPY followed by a DELETE and when you consider the issue of multi-resource locking. > > I don't know what the consensus is among the server folks but it seems to me that some of the server implementations might have problems dealing with these issues. > > The simplest solution seems to me to do the following > > 1. Disallow moving of locked or reserved resources (or at least resource locked as part of a multi.-resource lock) > 2. Specifically state that the correct behaviour in the case of a COPY is to NOT copy the locks or reservations. > 3. Change the definition of MOVE to be independent of COPY > > Cheers > Dylan
Received on Friday, 29 August 1997 18:47:59 UTC