- From: Sean Shapira <sds@jazzie.com>
- Date: Tue, 7 Jan 1997 17:04:55 -0800 (PST)
- To: ejw@ics.uci.edu (Jim Whitehead)
- Cc: sds@jazzie.com, w3c-dist-auth@www10.w3.org
Jim wrote: > The question is really whether "assisted" | "magic" move should be in the > HTTP interface to the repository. I totally agree with you that assisted > move should be in the *user* interface of an authoring tool. However, I > think the burden of proof rests on you to explain why assisted move should > be part of the semantics of MOVE, especially since HTTP is an > object-oriented protocol, and hence the scope of almost all methods is the > resource to which they are addressed. Having side-effects on other, > non-specified resources seems very undesirable from both an authoring and a > versioning standpoint. When a user requests an operation, they need to > know exactly what action will take place, and which resources will be > affected. Failure to do this will result in a lack of user understanding > and confidence in the functionality. Agreed. But perhaps examining a trivial assisted move example would help highlight the relationship between assisted moves and locking? Consider the case where foo.html and bar.html comprise the entire set of documents under DAV control, and the text of foo.html includes an "href=bar.html". An author decides it would be better if bar.html were renamed bat.html, and indicates an intent to make this change via some intuitive user interface. A sequence of operations to achieve this objective might include: 1. Rename the bar.html object (including its version history) to bat.html. 2. Update the foo.html object so that the text of its current version includes "href=bat.html" in place of "href=bar.html". 3. Create an object which ensures that http requests for bar.html are redirected to bat.html. If any of these operations fail while others succeed, the user will be unhappy with the result, so the client needs to ensure the server performs them in a way such that either all the operations succeed or all the operations fail. Does that match the concensus view of the WEBDAV community? Jim makes a convincing case above ("the scope of almost all methods is the resource to which they are addressed") that these should be handled by the client as 3 separate operations rather than hiding them within the server. So does current WEBDAV thinking have the client explicitly employ some sufficient set of locking mechanisms to ensure the success of all three operations (as a naive reading of draft-goland-http- webdav-00.txt might seem to indicate), or does the client use transaction-oriented operations (e.g. begin transaction, commit transaction, abort transaction) for this? -- Sean Shapira sds@jazzie.com (206) 443-2028
Received on Wednesday, 8 January 1997 00:28:31 UTC