RE: Assisted Moves and Lock/Transaction Handling

This has been an area of open debate. We all realize that we are getting
dangerously close to creating a transaction oriented system. Our current
solution is to take all three commands and wrap them in a
message/multi-part w/the atomic switch activated.

However it should be pointed out that currently there is no way for the
user to perform the third action. We do not support redirect in DAV.
This decision was made at the last technical meeting. So the best the
user could do w/DAV is send an atomic message/multi-part locking the two
files. Then send two messages making appropriate changes. The
redirection would have to be performed through another mechanism.

		Yaron

>-----Original Message-----
>From:	sds@jazzie.com [SMTP:sds@jazzie.com]
>Sent:	Tuesday, January 07, 1997 5:05 PM
>To:	ejw@ics.uci.edu
>Cc:	sds@jazzie.com; w3c-dist-auth@www10.w3.org
>Subject:	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 16:11:20 UTC