Re: COPY vs. MOVE on advanced collection references

I hate to snip out all the sections where we agreed (:-), but for the
sake of brevity, I'll just skip to the one section which raised a question:

   From: ccjason@us.ibm.com

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

   Yup. I agree.

OK, I left in one "I agree", but I need this one for context (:-).

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

   I don't necessarily agree here.  What I expect (or at least want)
   depends on what I'm doing at the time.

My turn to agree (:-).

   I think I'd tend to expect the reference to be copied.

The problem with copying just the reference shows up especially
vividly in a downlevel client (that doesn't even know about
references).  If I say "COPY", the key expectation that I can
now modify the copy-target without affecting the copy-source is violated.

The general rule I try to apply in these situations is:
If there are two reasonable things to do, so you need an extra parameter
(e.g. a header) do indicate which one you want, then have the
default be the one that does what a downlevel client would expect,
and have the presence of the header mean to "do the other thing".

In the case of "COPY" applied to a reference, this would seem to
say that the reasonable thing that the downlevel client would
expect (i.e. a copy of the reftarget of the reference) should be the
default, and the other reasonable thing (i.e. a copy of the
reference itself) should be indicated by a header.  The "no-pass-through"
header immediately springs to mind.

Cheers,
Geoff

Received on Tuesday, 2 February 1999 09:59:44 UTC