- From: Yaron Goland <yarong@microsoft.com>
- Date: Tue, 14 Oct 1997 15:18:39 -0700
- 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, Yaron > -----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