Re: Jason is getting MARRIED!

From: Bjorn Reese (breese_at_[hidden])
Date: 2019-11-24 11:53:25

On 11/17/19 3:38 PM, Vinnie Falco wrote:

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

Indeed you did, but thank you for succintly reiterating them anyways.

My question was more directed towards the community as a whole to find
out what they expect of a JSON library.

> 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

Been there, done that years ago:

 
http://breese.github.io/trial/protocol/trial_protocol/dynamic_variable.html

and contributed heavily to its prequel:

   https://github.com/ferruccio/dynamic-cpp

> * `json::value` is small (16/24 bytes on 32/64 bit architecture)

So most (all?) values are stored on the heap?

> 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.

Have been doing this for years:

   http://breese.github.io/trial/protocol/trial_protocol/core.html

> 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

The reason I am asking about these questions is that your current design
may not be suitable for making these extensions. You really should
consider building a Boost.Serialization input archive to investigate if
your design holds.

If your design becomes a Boost library, then there will be very little
incentive to include yet another JSON library to handle the remaining
use cases. That is why I am asking these questions up-front.

Notice that with the right design we can support all of these use cases
without making the library more complex.