- From: Yoram Last <ylast@mindless.com>
- Date: Tue, 20 Apr 1999 06:02:13 +0300
- To: w3c-dist-auth@w3.org
> >>>Using the term "move" for a "merge" is rather bogus, but with the > >>>prefacing statement, the user will know what they meant. > > >>>Here I'll disagree strongly. A "move" (i.e. "rename") command is > essential. > >>>A merge command is useful, but not a replacement for move. > > Ahhh.... > > The spec makes more sense when read that "Move" is a "Rename". But then > what is a "Copy"???? Is it a rename or a Copy?? This is confusing. > > I feel that Move and Copy should be made to be "Merge" type functions. I'm in agreement with you on this. Indeed, while there may be some questions concerning details of the implementation, the general principle that "Move and Copy should be made to be "Merge" type functions" seems like the most sensible way of implementing them. My reasoning (mostly applied to "move"; "copy" is similar) is the following: 1) Those that consider it linguistically wrong for a command like MOVE to do a merge type operation seem to focus their attention on the collection as being the main object which is being moved. However, it is equally legitimate to think of the collection as a container (or location) and to think of the content of that container as the main thing which is being moved. That is, "MOVE <col1> to <col2>" can be legitimately interpreted as saying: "move the content of <col1> into <col2>". 2) The behavior where a MOVE request does an implicit DELETE followed by a MOVE is neither useful nor desirable. It's not useful, because if a client wants to do that it can send a DELETE request and then issue a MOVE. The cost of sending two requests instead of one is very small. It's not desirable, because with a destructive operation of this type it is better to have the client issue an explicit DELETE rather than have it done implicitly. An implicit DELETE is something that should be avoided, except in cases where it is clearly the only way of doing things. Also, if the DELETE is done separately and it runs into a problem, then the client gets to decide what to do about it (which seems much better than having it arbitrarily decided by the server). 3) The "merge type" operations are clearly needed (see 4 below), and there is currently no other way of doing them short of moving individual resources. (In general, this might require a huge number of requests instead of one.) 4) The "merge type" behavior is how Windows Explorer does things (I suppose some other file managers do that as well. UNIX file managers don't usually do that, but they will usually not overwrite a directory unless it's empty, so they don't have the current WebDAV behavior either). Since it is clearly the most widely used file manager in the world, its behavior (logical or not) is what most people would expect. Furthermore, Microsoft would clearly want to have their web folders do things in this way (in order for them to be consistent with the rest of Explorer) and the current implementation actually assumes that MOVE/COPY have the "merge type" behavior. One can point fingers at them for not reading the spec (or for reading it and still doing things differently), but this won't solve the problem. They really do seem to have a legitimate need to have the "merge type" functionality, and I somehow doubt that they are going to recognize this as their bug and change it. They might say that it is the protocol which is bogus and needs to be fixed, and in this particular case, I think this is basically true. Yoram
Received on Monday, 19 April 1999 23:02:41 UTC