Re: Jason is getting MARRIED!

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2019-11-17 14:38:28

On Sun, Nov 17, 2019 at 3:45 AM Bjorn Reese via Boost
<boost_at_[hidden]> wrote:
> Before we get to that point, there are some questions

Yes these are good questions. I thought I had answered them but it
could certainly use more explaining (and in the documentation as
well).

In terms of parsing and serialization I don't think there will be any
single solution that will satisfy all use cases. The emphasis of my
JSON library is on the container that represents the JSON In memory.
It is designed to be useful as a vocabulary type. This means that if
someone wants to write a library that does things with JSON (e.g.
implementing JSON-RPC[1]), their public interfaces can confidently use
`boost::json::value`[2] in function signatures and declarations for
several reasons:

* `json::value` is SemiRegular
* `json::value` is small (16/24 bytes on 32/64 bit architecture)
* `json::value` behaves predictably with respect to special members (copy, move)
* `json::value` supports custom allocators (without being a template parameter)
* The physical structure of the value types is designed to reduce
compilation times:
  - No class templates
  - No configurability (well-defined, predictable behavior)
  - Strong separation of concerns
* The object[3], array[4], and string[5] types, used for the
underlying representation of
   the corresponding JSON kind, are first class types[3,4,5]
* All operations provide the strong exception safety guarantee

That said, parsing and serialization are still important and in this
area my library is quite competitive in terms of performance.
RapidJSON is currently the top-performing library for parsing and
serialization using a general purpose container (I don't count
SIMDJson, which produces a read-only structure). In comparison to
RapidJSON, my library outperforms RapidJSON in most cases and
completely blows away nlohmann [6].

This library also supports both incremental parsing and incremental
serialization using caller-provided buffers, an important use-case for
building high performing network programs. To my knowledge no other
JSON library supports this.

> These days there are a huge number of JSON libraries out there. Some
> focus on features (e.g. binary JSON or JSONPath), others on performance,
> and others on user-friendliness. What competitive edge should a
> potential Boost JSON library offer?

A problem that I see with some other libraries is that they attempt to
do too much, resulting in poor API designs with no separation of
concerns, and long compilation times. Something that I am doing these
days, based on things I've learned while maintaining Beast, is to
design my new libraries differently:

* Keep the scope narrow: solve one problem and solve it well
* Minimize the use of templates where doing so does not diminish functionality
* Design with modularity in mind: minimize dependencies
* Be mindful of compilation times

This new thinking addresses the most common complaints that users have
about Boost libraries. A planned feature is to enable this JSON
library to be used without Boost simply by defining
BOOST_JSON_STANDALONE. This way stubborn users who refuse to use boost
because Reasons can still enjoy a wonderful JSON library.

> Which use cases should a potential Boost JSON library support? Should
> the library work seemlessly with standard algorithms?

I'm not sure what supporting standard algorithms means, but the
object, array, and string containers have interfaces that are
identical to their C++20 equivalents (unordered_map, vector, and
string) except that for the `object` type:

* The elements are stored contiguously
* Iterators are ordinary pointers, and may become invalidated on
  insertions and removals.
* The order of insertions is preserved, as long as there are no removals.
* All inserted values will use the same allocator as the container itself.
* All hash, bucket, and node interfaces are removed

> Should it be
> possible to create parser combinators? Should there be a JSON archive
> for Boost.Serialization? Should it replace parts of Boost.PropertyTree?

These are out of scope for my library. If parser combinators are
important, they can be developed as a separate library. The same goes
for bindings for Boost.Serialization and Boost.PropertyTree. Generally
speaking, I think new Boost library offerings need to be more
numerous, smaller, modular, and with fewer dependencies from now on. I
would like to break up Beast into 4 or 5 individual libraries at some
point (the logistics of that being not-yet-determined).

Thanks

[1] <https://www.jsonrpc.org/specification>
[2] <https://vinniefalco.github.io/doc/json/json/ref/boost__json__value.html>
[3] <https://vinniefalco.github.io/doc/json/json/ref/boost__json__object.html>
[4] <https://vinniefalco.github.io/doc/json/json/ref/boost__json__array.html>
[5] <https://vinniefalco.github.io/doc/json/json/ref/boost__json__string.html>
[6] <https://vinniefalco.github.io/doc/json/json/benchmarks.html>