The key advantage to the current syntax is that it's just absolutely drop
dead simple. I get what you're saying but I'd rather avoid increasing the
complexity of the syntax any more than we absolutely have to. And, to be
absolutely honest, I haven't yet seen an actual application case where it's
been an issue (that's not to say they don't exist, just haven't seen it in
practice yet). What's your suggestion for making the syntax better?
On Mon, Dec 17, 2012 at 7:41 PM, Robert Sayre <sayrer(_at_)gmail(_dot_)com>
wrote:
On Mon, Dec 17, 2012 at 7:08 AM, James M Snell <jasnell(_at_)gmail(_dot_)com>
wrote:
Everyone's idea of "bloat" is different.
What I meant was that the predicate additions increase the size of the
protocol messages. Your example is twice as large. The check could be
more efficiently represented in the path notation or the operation
names.
Again, the point is, I don't see this as a problem in practice.
Implementers
that make blind edits to arbitrary docs can expect surprising results
sometimes. That's just the way it is. There are mechanisms defined (test,
json-predicates and conditional requests) that can make the edit more
reliable.
Well, one way of putting it would be that the patch format makes it
difficult to ensure convergence at quiescence in OT software when
there's a change in type from array to object or vice-versa:
<http://en.wikipedia.org/wiki/Operational_transformation#The_CC_model>
There's no good reason for it to be that way, is there?
- Rob