Re: [apps-discuss] JSON patch: "test" operation

I can project cases where multiple operations are performed, and you
can't determine the state until an operation is completed before being
in a position to test for the next operation. Forcing tests to be up
front will needlessly complicate diff implementations, will not reduce
any complexity on patch implementations, for no good reason as far as I
can tell

Paul 

On Thu, 2011-12-01 at 14:01 +0100, Julian Reschke wrote:

> On 2011-12-01 13:47, Carsten Bormann wrote:
> > On Dec 1, 2011, at 13:37, Julian Reschke wrote:
> >
> >> On 2011-12-01 13:26, Carsten Bormann wrote:
> >>> What happens when a test fails?
> >>> -- Keep or rewind the changes done so far?
> >>> 	(or do we stipulate "test" has to come before modifiers?)
> >>
> >> I think requiring them to come first makes a lot of sense.
> >
> > I think so, too.
> > (Still, something should be said about what is supposed to happen if they don't -- is that a MUST detect then?)
> 
> I would support that (MUST occur first).
> 
> > My comment ("what happens") can be generalized to the entire section 5 of draft-pbryan-json-patch-02.txt…  "Fails to complete" doesn't cut it, I think.
> >
> >>> -- What is the response code you want to see?
> >>
> >> 409 comes to mind.
> >
> > Sounds good.  I think that the media type spec should contain text suggesting a specific response code, to rein in the otherwise uncontrollable inventiveness of the implementers.  Could go in section 5, too.
> 
> Not sure. I think 
> <http://greenbytes.de/tech/webdav/rfc5789.html#rfc.section.2.2> is quite 
> clear on that.
> 
> Best regards, Julian
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss