COPY vs. MOVE on advanced collection references

I promised Adv. Coll. design team I'd start a thread on this topic,

The expected semantics of MOVE is that I end up with the same stuff
at some new location, and even a hope that appropriate references to
the old stuff ends up pointing at the new stuff (i.e. that business
about updating things between the COPY and the DELETE).

The expected semantics of COPY is that I end up with a different
object, so that I can modify one copy and have it not affect the other.

Now let's look at what a MOVE on a reference should be.  It's pretty
clear that you just want to have a copy of the source reference created
at the destination.  If you look at how both hard-links and sym-links
are implemented in file systems, this is exactly what happens.

But now let's look at what a COPY on a reference should be.  
If you just make a copy of the reference, then any PUT to the
source object will cause a modification visible in a GET to the
destination object, and vica versa.  This is the opposite behavior
from what one would expect from a "copy", and seems to violate
the whole point of differentiating a "MOVE" from a "COPY".

One alternative is to revisit the definition of MOVE as a kind
of COPY.  Part of me says that is the right choice, since many
(or even most) systems treat MOVE as a "rename", not as a copy
followed by a delete, i.e. it is a change to the namespace, not
to the object being moved.  This means that the current definition
will keep getting us into trouble (as I believe it will in the
case of locking a collection), since it forces the server to treat
a cheap operation (rename) as an expensive operation (a recursive
create, followed by a recursive delete).  It's like forcing every
"mv" to be a "tar" followed by an "rm -r".

On the other hand, for simple resources and simple collections, the
current definition works reasonably well, so it would be worth trying
hard to find an alternative that does not re-open the existing spec.
One such alternative would be to say that the COPY automatically
invoked by a MOVE is "no-passthrough" by default (i.e. like DELETE),
while an explicit COPY is passed through references (i.e. like a GET
or a PUT, whose behavior we want to affect).  This does "override" the
original spec, but only when applied to references, which is probably
more acceptable, since references are after all being defined in the
Adv. Coll. spec.

Either alternative is fine with me.

Cheers,
Geoff

Received on Tuesday, 2 February 1999 05:20:41 UTC