- From: <jamsden@us.ibm.com>
- Date: Fri, 3 Sep 1999 09:50:44 -0400
- To: w3c-dist-auth@w3.org
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