Replication vs Cloning (was: Bindings, Locks, and MOVE)

Geoffrey M. Clemm writes:
 > Is anybody going to be implementing cross-server MOVE as anything
 > more than a cross-server COPY followed by a DELETE?  

A cross-server MOVE has to be more than just a cross-server COPY
followed by a DELETE, unless the COPY is a full replication rather than
mere cloning, or the MOVE is a mere cloning rather than a full replication.

Are you suggesting that such a cross-server MOVE would always result in
a new resource rather than the same resource at a different location?

To clarify, what I mean by a replica is a true copy, like a clone but
with the additional property that any change to one replica should be
reflected in all other replicas.  Perhaps replicas could be or should be
built on top of WebDAV at a higher level, but the D in WebDAV is already
about managing copies of resources to support remote authoring in such a
way that all the copies appear to be consistent replicas.  That is why
we have locks in the first place, although there are other techniques
for managing consistency.

 > The reason
 > I ask is that it is a MOVE that has all the tricky interactions
 > with multiple bindings and locks, while a COPY is relatively
 > straightforward (new resources are created, so bindings and locks
 > are not affected).
 > 
 > In particular, I'd advocate making cross-server COPY's a MUST
 > (or at least a SHOULD), while a cross-server MOVE's a MAY
 > (or at most a SHOULD).  My main argument against MOVE is that
 > unless the "fixup" step that comes between the logical
 > "COPY and the MOVE" is well defined (as it is in the
 > advanced collection spec), the MOVE semantics is so vague
 > as to be useless.

I agree that it would be bad to have MOVE mean "same resource" in one
case (same-server) and "different resource" in another case
(cross-server).  Whether a resource ends up on the same server or not
should be irrelevant.  Even within the same server, the resource might
move across file system boundaries which requires the equivalent of a
copy.

 > Then a client that wants the COPY/DELETE form of "MOVE" can just
 > issue a COPY followed by a DELETE.

We should distinguish these two cases.  I'll call the first replica-MOVE
and the second clone-MOVE.  Similarly, we can distinguish two forms of
COPY: replica-COPY and clone-COPY.  A replica-MOVE can be implemented as
a replica-COPY followed by a DELETE.  A clone-MOVE can be implemented as
a clone-COPY followed by a DELETE.

Another important difference between the one MOVE operation and the
two operations COPY followed by DELETE is whether the combined operations 
are atomic.  For a clone-MOVE, this atomic property is (probably) not an 
issue unless someone needs to know that a new resource has been created
before the old resource is deleted.  For a replica-MOVE, the atomic 
property is important if someone is given write access to the old replica
after the replica-COPY but before the DELETE since the new replica may not
expect any changes to occur via the old replica.

I don't know why the replication operations are that difficult to
implement, although I can see that they are more difficult than cloning.
I know there is much more work involved in maintaining replicas than
initially making replicas.  But I suggest that since WebDAV is intended
to support some form of replication (i.e. distributed authoring) the
specifications should do one of two things:

1. Add support for replication, both replica-COPY and replica-MOVE in
   addition to clone-COPY and clone-MOVE, both same-server and
   cross-server.

2. Include enough support to allow applications to build
   all those operations on top of WebDAV.

In any case, we should be clear about the level of support WebDAV has
for replication, whether it is only same-server replica-MOVE, or
build-your-own replication via atomic LOCKs.

-- 
Daniel LaLiberte
liberte@w3.org

Received on Tuesday, 7 September 1999 13:19:54 UTC