Re: [review] [json] My JSON review

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2020-09-21 14:23:34

On Mon, Sep 21, 2020 at 6:11 AM Mathias Gaunard via Boost
<boost_at_[hidden]> wrote:
> I believe that the library should be REJECTED

Thank you for taking the time to review the library.

> - The interface is closely tied to a text format and doesn't support
> JSON-inspired binary formats.

"JSON-inspired binary formats" are not JSON. CBOR for example is
"JSON-inspired", yet neither Node.js nor any web browser support it.
They do however support standard JSON, and their respective DOMs have
numerical limitations similar to the ones in Boost.JSON.

> - The fact that only a push parser is provided. Parsing into own types
> usually requires a pull parser in order for nested member's parsers to
> combine into the outer parser.

It seems to me that there are two non-overlapping use-cases:

1. Parsing and serializing standard JSON to and from a
library-provided DOM container

2. Parsing and serializing standard JSON to and from user-defined
types, with no intermediate DOM container representation.

Boost.JSON addresses number 1 above, and in my opinion it accomplishes
that goal with the level of performance and interface clarity that the
world expects of a Boost library. Number 2 above is still useful
functionality, but there is not a lot of implementation that could be
shared in a library that attempts to do both (you could probably share
the escaping of strings and output of numbers).

I do not think it is possible for a single parser API and single
serializer API to address both of these use-cases well. Optimizing for
one will necessarily come at the expense of the other. Perhaps there
is a hypothetical not-yet-written library just waiting to be
discovered which will prove me wrong, by doing everything well. I have
my doubts.

It seems to me that these are two separate libraries.

> The DOM does not support numbers that are neither 64-bit integral
> numbers nor double-precision floating-point. This is a common
> limitation, but still quite disappointing, since the proposal of it
> being a canonical type is quite tainted by the fact it can't represent
> JSON data losslessly. I think it would be better if another type was
> provided for numbers that don't fit in the previous two categories.

I disagree. Serialization of a canonical type should produce JSON that
is interoperable with the majority of receivers. Neither Node.js nor
browser implementations of JSON understand arbitrary precision
integers out of the box. Unless the receiver is configured to process
it, emitting an arbitrary precision number is certain to cause a
compatibility problem.

In fact the entire goal of RFC 7493
(https://tools.ietf.org/html/rfc7493) is to specify additional
constraints on JSON values to maximize interoperability. Boost.JSON
loosely follows these guidelines by restricting itself to 64 bit
integers and floats.

> Querying capabilities for that type are pretty limited and quite
> un-C++ like. Examples use a C-style switch/extractor paradigm instead
> of a much safer variant-like visitor approach.

visit() is a planned feature which is already implemented:

<https://github.com/vinniefalco/json/tree/visit>

> There is no direct nested xpath-style querying like with boost
> property tree or other similar libraries.

JSON Path and JSON Pointer are planned features:

<https://goessner.net/articles/JsonPath/>

<https://tools.ietf.org/html/rfc6901>

> When it comes to serializing floating-point numbers, it seems it
> always uses scientific notation. Most libraries have an option so that
> you get to choose a digit threshold at which to switch.

Yes the conversion from floating point to string is an area of
research and improvement.

> is otherwise quite
> limited as it is unsuitable for any use of JSON as a serialization
> format for otherwise known messages.

That is by design. Boost.JSON is not a serialization library. It
addresses the use case for a JSON DOM with accompanying parser and
serializer. This is not an insignificant use-case; witness the
popularity of RapidJSON and nlohmann's JSON for Modern C++. In fact
didn't you say you are already using RapidJSON?

Thanks