Subject: Re: Bindings, Locks, and MOVE

From: [email-masked]
Date: Fri, 3 Sep 1999 09:50:44 -0400

DAV4J does do cross server COPY and MOVE. This is an important function required
to support publishing web applications. DAV4J does it by reusing GET/PROPFIND
and PUT/PROPPATCH (followed by DELETE if MOVE). The handling of live properties
is a little tricky as PROPPATCH doesn't have anything like a propertybehavior
element to specify what to do with the live properties like COPY and MOVE (I
have proposed and extension to PROPPATCH that allows the client to specify how
to handle errors on individual properties, see below). DAV4J does it for now by
attempting the PROPPATCH, looking at the properties that failed, removes them
from the PROPPATCH, and tries again. I know this isn't ideal, is an instance of
server-to-server communication, and it makes COPY and MOVE very sloooooow, but
its the best we could do for now.

Proposed extensions to PROPPATCH:

1. Extend the DAV:set and DAV:remove elements to include information describing
how the client wishes to handle errors. The DTD additions would be:

<!ELEMENT propertyupdate (remove | set)+>

<ELEMENT set (prop, updatebehavior?)>
<ELEMENT remove (prop, updatebehavior?)>

<!ELEMENT updatebehavior (ignore | mustsucceed)>
<!ELEMENT ignore EMPTY>
<!ELEMENT mustsucceed (#PCDATA | href+)>

If an updatebehavior is not included, it is equivalent to specifying
<mustsucceed>*</mustsucceed> meaning that all the updates must be successful or
none of them are performed. If a list of URIs is included as the value of
mustsucceed, then the named properties must be updated successfully. The #PCDATA
in element mustsucceed can only be "*" indicating all updates must be
successful. If ignore is specified, then the server must use best effort to
update the properties returning a multistatus indicating which properties were
not updated.

Currently, the spec says that all property updates must be successful, or none
are applied. In many instances, this is too restrictive requiring clients to
submit PROPPATCH requests, examine the multistatus returned to figure out which
updates failed, and re-submit a new PROPPATCH with the failures removed. This
situation arrises when different servers support different live properties. The
above extension to PROPPATCH allows client applications to have more control on
setting properties.

2. Add an add element to propertyupdate to distinguish between setting an
existing property and adding a new property.

Currently, propertyupdate includes set and remove. A client can either set the
value of an existing property, or add a new property with the set element. There
are some cases where the client does not want to set an element that already
exists, but there is currently no way to distinguish these operations in the
propertyupdate element. The extension provides an add element that would add a
new property to the resource. The add update would fail if the property already
has a value. This extension will be more important if we add extension 1 because
there will be many cases where a property should not be updated after it has
been set. For example, resourcetype, creationdate, etc.

---

From: John Stracke <[email-masked]>
Date: Fri, 03 Sep 1999 10:59:36 -0400

I like this idea; I just have a syntactic quibble:

> <mustsucceed>*</mustsucceed>

It might be better if, rather than using "*", you defined an <all/> element meaning
the same thing.  For now, "*" is simple enough; but, if we add more wildcards
eventually, then it gets messier; we'd have to add more possible values, which
starts getting into defining a separate syntax, with a separate parser.  Simpler to
use XML tags and let the existing parser handle it.

--
/============================================================\
|John Stracke    |http://www.ecal.com|My opinions are my own.|
|Chief Scientist |===========================================|
|eCal Corp.      |Campbell's has it wrong--it's "Never       |
[email-masked]|underestimate the power of *chocolate*".   |
\============================================================/

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Sat, 4 Sep 1999 20:56:55 -0400

From: [email-masked]

   DAV4J does do cross server COPY and MOVE. This is an important
   function required to support publishing web applications. DAV4J does
   it by reusing GET/PROPFIND and PUT/PROPPATCH (followed by DELETE if
   MOVE).

Let me modify Greg's question just a bit:

Is anybody going to be implementing cross-server MOVE as anything
more than a cross-server COPY followed by a DELETE?  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.

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

Cheers,
Geoff

---

From: Daniel LaLiberte <[email-masked]>
Date: Tue, 7 Sep 1999 13:19:40 -0400 (EDT)

Geoffrey M. Clemm writes:
 > 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 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.

 > 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
[email-masked]