On Sun, Jan 6, 2013 at 3:35 PM, Paul C. Bryan <pbryan(_at_)anode(_dot_)ca>
wrote:
Thank you for the technical response.
1) The ambiguity around arrays makes the patch format unsuitable for common
concurrent editing algorithms.
Common concurrent editing algorithms should, in my opinion, use techniques
to ensure the state of the resource (relative to the edits) is known. In
HTTP, we have ETag and If-Match/If-None-Match preconditions. In JSON Patch,
we have (a rudimentary) test operation.
That is sequential editing, not concurrent editing. Here are a few
links to make sure we're not talking past each other:
http://en.wikipedia.org/wiki/Operational_transformation#Basics
The above overview section contains a two-step insert/delete process
bearing an uncanny resemblance to a JSON Patch document.
Here's some software that uses patch documents in this fashion:
http://en.wikipedia.org/wiki/Operational_transformation#OT_software
[snip]
3) It's not possible to tell whether a JSON Pointer document is
syntactically correct in isolation.
There is no such thing as a JSON Pointer document.
Yes, I meant JSON Pointer /reference/. This error seems tangential to
the thread in general, though, which is why I didn't bother to correct
myself when others raised this point.
This issue is a problem in practice, and it's a problem in theory as well.
JSON-Patch messages aren't sufficiently self-descriptive, so they aren't
appropriate for use in a RESTful system.
99% of RESTful systems I'm familiar with are based on HTTP. Where optimistic
concurrency is acceptable, HTTP preconditions seems to provide acceptable
coverage. Where more granularity or more pessimistic concurrency is
required, implementors are free to use their own mechanisms, including more
expressive predicates (as has been proposed here, with my endorsement)
and/or resource locking. These are intentionally out of scope for JSON
Patch.
Fully disagree. My point is that the array ambiguity makes it hard to
implement more optimistic concurrency.
Later in this thread, you wrote:
Ah. I meant that the WG seems to be favoring "running code" a little too
heavily in the presence of a bug. It's an old argument, and it's boring: "We
can't change it now, there are already twelve users!"
I don't agree that this is a bug; it lacks a feature that you and some
others have requested.
The only rationale I've seen prior to my message was something about
"feeling natural" and "static languages" that I admit I don't fully
understand. Are there other technical arguments I've missed? I'm happy
to go read up.
Our reasoning for resisting such change is
legitimate.
This last assertion really isn't qualified very well. Do you have a
more extensive rationale, or is a simple contradiction the extent of
your argument?
- Rob