W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1999

RE: Move for Collections

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Fri, 12 Feb 1999 09:47:06 -0800
To: Rob Frost <froker@ix.netcom.com>, w3c-dist-auth@w3.org
Message-ID: <005a01be56af$b49ce800$d115c380@galileo.ics.uci.edu>
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/.


> 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


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


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
- 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
 - 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:16 UTC