Assisted Moves and Lock/Transaction Handling

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