Re: Fun with Moves and Copy

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