Re: Comments on the "new" 2518

I am on the fence for how to go with this issue,  but I do note that  
your solution doesn't solve John's problem.  There are many existing,  
deployed clients who already implement MOVE and John wants WFS to  
behave appropriately for them without forcing widespread client (in  
some cases, operating system) upgrade.

Lisa

On Mar 6, 2006, at 1:16 PM, Geoffrey M Clemm wrote:

>
> The BIND specification (which hopefully will be last-called soon after
> the 2518bis last-call is completed), provides this feature in the  
> REBIND
> method.  So rather than upgrade your sever to support a new header,  
> you
> would upgrade your server to support the REBIND method.  Similarly, if
> you wanted to provide atomic DELETE functionality, you would  
> support the
> UNBIND method.
>
> Cheers,
> Geoff
>
> John wrote on 03/06/2006 02:33:57 PM:
> >
> > 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
> >
> >
> >