Re: Comments on the "new" 2518

John Barone wrote:
> The concern for us on a MOVE is that the currently specified behavior is
> contrary to (what our immediate customer experience tells us) many users
> want or expect.  Imagine that I as a user issue a MOVE on the server via an
> integrated file explorer on the desktop.  I start out with a whole
> collection, and I drag-and-drop it to a new location on the server (or
> simply rename it), and I end up with 2 incomplete collections, due to
> permissions or lock conflicts on sub-collections/resource, with no real
> indication as to why it happened, and worse, no indication how to correct
> the mess I've just created.  Our own customer experience tells us that, in
> this use case, users don't want you to allow them to "shoot themselves in
> the foot".
 > ...

For the record: but that's exactly the same behavior that the user gets 
when moving data across partitions or network shared.

 > ...
> So, understanding that the specification of MOVE behavior has not changed
> between 2518 and 2518-bis, Xythos would like to propose the following
> additional capability to the MOVE section:
> Add support for a new header on MOVE, that will allow client applications to
> request that the server perform an atomic operation on MOVE, meaning an
> all-or-nothing operation.  We'd like to see the header:
> Allow-partial: T/F
> ... added for MOVEs, with the default value being 'T', to preserve
> backward-compatibility, and a value of 'F' meaning attempt to perform the
> MOVE as an all-or-nothing operation; if the MOVE cannot be performed as an
> all-or-nothing operation, return a 412 - precondition failed response (or,
> alternatively, a 207 response, that includes all the 412 response for
> specific resources).  If implementing servers choose not to support this
> header, and the value is set to 'F', they MAY return a 400 bad request
> response.   
> ...

So what will the client do if the server fails the request? Retry with 
Allow-Partial: T? How would that be reflected in the UI?

Best regards, Julian

Received on Tuesday, 7 March 2006 08:45:00 UTC