Re: FW: Circular Bindings

<GC>
   ... this also reminds me that with AdvColl, it is possible that a
   portion of the source tree and the destination might be common.  And
   that initial deletion phase of the COPY might actually essentially
   delete a portion of the source tree.  It's probably a red herring, but
   it's probably also something we should mention in the spec.

I agree that it is something that should be explicitly mentioned
(and disagree that it is a red herring :-).

In particular, I'd suggest some words to the effect that a COPY should
be semantically equivalent to a COPY to a temporary URL (that identifies
a null resource) followed by a MOVE from the temporary URL to the
destination URL.
</GC>

Geoff, I don't understand your wording.  Whoops.  Yes, I do.  The COPY would
create a new instance of the resources that were in the source tree.  The MOVE
would UNBIND the destination and rebind the newly created copy to the
destination URI.  (Am I using our "bind" vocabulary/object-model correctly? :-))
Got it.  Of course, that's the AdvColl. way of explaining it.  And it still has
this odd behavior with the the DELETE phase if we use your wording with
RFC2518... so we still should flag it there.     Hopefully we can move to
AdvColl. and not worry too much about this.  (It's only a problem for AdvColl if
the UNBIND of the MOVE phase destroys a binding that happens to be in the source
tree.  Fortunately that one binding is the only thing that gets destroyed (at
least explicitly) as a result of the COPY.  I said explicitly because a bunch of
resources might lose their only mapping(s) as a result of that unbind and thus
become inaccessable in the absense of versioning.)

The caveat is... even with AdvColl, I think we need to define what COPY/MOVE do
across machines that don't cooperate on bindings.  Your definition of COPY seems
to work across machines as long as we say the COPY phase copies to a temporary
location on the *destination* machine.  MOVE across machines is another matter.
We should say if we allow MOVE if the intended semantics can't be achieved.  Or
if best effort is acceptable.  Or if the client can specify if best-effort is
acceptable.

Received on Friday, 13 August 1999 20:24:03 UTC