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@xxxxxxxxx> wrote:
On Mon, Dec 17, 2012 at 7:08 AM, James M Snell <jasnell@xxxxxxxxx> wrote:What I meant was that the predicate additions increase the size of the
>
> Everyone's idea of "bloat" is different.
protocol messages. Your example is twice as large. The check could be
more efficiently represented in the path notation or the operation
names.
Well, one way of putting it would be that the patch format makes it
> 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.
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