Re: Bindings, Locks, and MOVE

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.

Received on Friday, 3 September 1999 09:53:45 UTC