RE: Comments on the "new" 2518

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".

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.   


-John 

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On
Behalf Of Julian Reschke
Sent: Thursday, March 02, 2006 12:24 AM
To: Kevin Wiggen
Cc: w3c-dist-auth@w3.org
Subject: Re: Comments on the "new" 2518


Kevin Wiggen wrote:
> In section 9.1, I know this isn't backwardly compatible but can't we 
> make the default for PROPFIND = depth 0 and PROPNAME?  Move, Copy, 
> Delete aren't backward compatible (see other email), why not make this 
> better.

MOVE, COPY and DELETE *are* backwards compatible.

And that's exactly the reason why we didn't make changes like the one you
just proposed: old clients should be able to interact with new servers, and
the other way around. Note that this is the main reason why I'm opposed to
change the LOCK refresh marshalling.

Best regards, Julian

Received on Monday, 6 March 2006 19:34:07 UTC