RE: Comments on the "new" 2518

So, Xythos' opinion is actually that MOVE should be atomic.  That's what our
customers tell us they expect, that's what we want to provide for them.  And
honestly, I can think of a real good reason why I'd want to start off with a
whole collection, and end up with 2 incomplete collections, that have to be
cleaned up.  This not only causes problems for the user who performed the
operation, but also, potentially, any users that had/have read access to the
collection(s) (source and/or target).  

I was trying to strike a middle ground, since what we're proposing is a
change to the spec.  The bottom line, is that we'd much prefer the spec.
changed to say that MOVE SHOULD be atomic, meaning all-or-nothing, and then
provide some mechanism (maybe Header) to indicate otherwise.  Yes, our
proposed "compromise" would require clients to change, so in that sense it's
not ideal from our perspective.  We could change our client technology to
make use of the proposed header, but other ubiquitous clients (i.e. Web
Folders, MS Dav Client, Mac Dav Client) would not necessarily do likewise,
and would result in a less than ideal solution for our customers.  I don't
see the suggestion of implementing REBIND as a workable solution, since that
entails implementing/supporting an entirely different spec. for both server
and client, introducing a whole host of additional requirements and
functionality.  While Xythos can certainly choose to implement the Bind
spec. on its server, there's nothing to say that clients (particularly the
most ubiquitous ones our customers are using) would follow suite; in fact,
I'd venture to say they wouldn't, at least not in the foreseeable future.
Besides, what we're talking about is the basic WebDAV spec. (2518,
2518-bis), which has established client and server applications supporting
it.  I don't see suggesting the use of REBIND (which means implementing the
Bind spec.) as particularly germane to this discussion.  The issue at hand
is the behavior and functionality provided by the MOVE method.

Regarding your comments Julian...

>For the record: but that's exactly the same behavior that the user 
>gets when moving data across partitions or network shared.
     
... not sure what OS/filesystem you're referring to here, but if I recall
correctly, on Windows, if you try to drag-and-drop a directory across drives
(local or network), the OS/filesystem will actually force a copy, and thus a
best-effort result would be expected, and is not in dispute (for COPY) by
Xythos.

Regards,

-John 
 

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Tuesday, March 07, 2006 12:44 AM
To: John Barone
Cc: 'Kevin Wiggen'; w3c-dist-auth@w3.org
Subject: 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 Thursday, 9 March 2006 16:36:01 UTC