- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 07 Mar 2006 09:43:58 +0100
- To: John Barone <jbarone@xythos.com>
- CC: 'Kevin Wiggen' <kwiggen@xythos.com>, w3c-dist-auth@w3.org
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