W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1997

RE: WebDAV Tree Operations

From: Yaron Goland <yarong@microsoft.com>
Date: Tue, 14 Oct 1997 15:18:39 -0700
Message-ID: <11352BDEEB92CF119F3F00805F14F48503DFC7D1@RED-44-MSG.dns.microsoft.com>
To: "'John Turner'" <johnt@cgocable.net>, w3c-dist-auth@w3.org
A lot of people agree with you, that these operations may not be worth
the added cost. That is why the tree draft is a completely separate
draft from the main WebDAV protocol spec. It is a set of completely
optional methods.

DELETE-TREE - I suspect you are right about just having the delete on
the parent fail. I will change the text.

COPY-TREE - However I disagree with your comment about a failure on the
parent should fail the children. Most systems implement bottom up so it
is perfectly reasonable for them to copy over the children but not
necessarily the parent. There is no guarantee with the tree methods that
you will get a perfect COPY over all the resources copied.

Copying over an existing destination - But that isn't what it does. It
specifically states that it merges the properties and members if there
is an existing destination with conflicts being resolved by the source
overwriting the destination.

Delete failure and MOVE-TREE - I agree, I will clean up the language.

		Thanks for the comments,

> -----Original Message-----
> From:	John Turner [SMTP:johnt@cgocable.net]
> Sent:	Tuesday, October 14, 1997 2:15 AM
> To:	w3c-dist-auth@w3.org
> Subject:	Re: WebDAV Tree Operations
> The three tree operation methods definitely fill a void.  My feeling
> is that
> some additional level of control for  multiple copies would be useful,
> but I
> am not certain whether it is worth the added complexity.
> My one negative comment on the draft is that I do not like the way the
> failed operations are handled.  I do agree that the namspace
> consistency is
> important, but think that it can be maintained differently.
> For DELETE-TREE, if a resource cannot be deleted, I would prefer that
> the
> parent collection fail as well, rather than having it succeed but a
> new
> collection created in its place.  Creating a new collection after
> having
> deleted the original leaves the remaining collections in a strange
> state,
> not gone, but not what they were before the delete.
> In a similar way, I think that with the COPY-TREE, if a collection
> fails to
> copy, then its members should fail also, or in fact may not even be
> tried at
> all.  If it fails, but its children are copied, you have an imperfect
> copy.
> Children are there, but the parent is not consistent with the
> original.
> The COPY-TREE description should probably state that copying over an
> existing destination should delete the destination (similar to what it
> says
> for MOVE-TREE).
> The MOVE-TREE specifies that a move onto an existing collection must
> delete
> it.  It does not say if the move should continue if the delete (or
> DELETE-TREE) fails.  I would especially dislike having it move over a
> destination that was deleted, then recreated because a member could
> not be
> deleted.
> John Turner
> johnt@cgocable.net
Received on Tuesday, 14 October 1997 21:59:14 UTC

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