RE: Move for Collections

Hi Rob,

> I wanted to clarify my understanding of the MOVE operation for collection
> resources. In section 8.9.2 "MOVE for Collections", it states:
>
>    So, for example, if an infinite depth move is performed on
>    collection /a/, which contains collections /a/b/ and /a/c/,
>    and an error occurs moving /a/b/, an attempt should still
>    be made to try moving /a/c/.

Right.

> If the /a/c/ move is successful, what happens to /a/b/? I'm assuming we
> would get the following result:
>
> - collection /a/ and the /a/c/ subtree will be copied to the destination

Right.

> - collection /a/ and subtrees /a/b/ and /a/c/ will be deleted from the
> original location

Nope.

The design principles we used here are:

- perform a best-effort move if errors are detected (which assumes the user
really wanted the move, and would prefer a partial move over a complete
failure)
- do not accidentally delete data
- the way to view a depth operation is that the methods are being passed
from the collection to its members, then executed by each member.  The tree
traversal algorithm is intentionally unspecified -- it could be depth-first
or breadth-first, etc.

So, what should happen is:

 - collection /a/ and subtree /a/c/ will be copied to the destination
(including all members of /a/).
 - subtree /a/c/ will be deleted.
 - all resources in /a/, excepting /a/b/, are deleted (since they have been
copied)
 - collection /a/c/ is untouched.
 - collection /a/ must remain to maintain a consistent namespace

Of course, each individual move operation is performed as a logical atomic
operation -- my discussion above separates out the copy and delete steps for
expository reasons.

> If this is the intended behavior, it seems to conflict with the
> atomicity of the move method (copy then delete) on resource /a/b/: the
> resource will have been deleted without being copied.

True -- since this is a violation, the resources aren't deleted, since they
weren't copied.

> I haven't been looking at the WebDAV stuff for very long, so I
> apologize if this has already been discussed or I'm missing something
> obvious.

No problem -- if you have a question, others likely do too.

- Jm

Received on Friday, 12 February 1999 12:57:28 UTC