Deeper look at RFC7159: the revised specification of JSON Urabe, Shyouhei. DeNA Co., Ltd.
New RFC to specify JSON was released last month!
So I created a new gem
Why another JSON library?
So a conforming JSON library … ● MUST always generate JSON text that STRICTLY conforms the RFC, without ANY extensions such as NaNs. Otherwise that generator is not a conforming JSON library. ● MUST always understand ALL expression that the RFC permits, NO MATTER HOW strange that specific expression is, or even impossible to represent in Ruby. Otherwise that parser is not a conforming JSON library. This is hard!
How to tackle this situation
Line-by-line translation into racc and…
… and 100+ acceptance tests.
Some interesting cases include:
This is by design, but out of date.
Should I stop using Yajl / Oj ? ● I don't think so. ● They are useful. Just having little bugs. All programms do so more or less. I don't want to point them at finger. ● On the other hand, the library I created is strict-but-useless. It exhibits paranoia behaviour, too strict to reject converting most Ruby objects into JSON, while too tolerant to accept almost any texts, and most importantly, RUNS TOO SLOW.
Fast enough to take 1.6+ secs for parsing 32KB
Maybe JSON needs better trade-offs ● Proper treatments of evil escapes, like [”\uD800”], is the nightmare that causes this slow-down. ● Ignoring them only should greatly speed things up. ● JSON spec might better be updated to explicitly forbid invalid sequences, even if they are escaped. ● Everyone should stop generate such thing today.