On Mon, Sep 21, 2020 at 6:11 AM Mathias Gaunard via Boost
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