Re: Jason is getting MARRIED!

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2019-11-30 16:55:59

On Sat, Nov 30, 2019 at 7:33 AM Bjorn Reese via Boost
<boost_at_[hidden]> wrote:
> your JSON library supports a rather limited set of use-cases that
> excludes Boost.Serialization style serialization, whereas Trial.Protocol
> supports the same use-cases and many more with simpler building-blocks.

I think that we need to be precise with terminology. The three
components of the library I am proposing are thus:

1. Container types (value, object, array, string)
2. Storage API (storage_ptr, storage, scoped_storage, pool)
3. Parser and Serializer

When you say "excludes Boost.Serialization style serialization" I
believe you are referring only to the Parser in the list above.
Specifically, that a parser which extracts and returns a token at a
time, rather than consuming the entire input buffer and invoking a
callback, is a more fundamental building block as it enables more
use-cases. Please let me know whether this is an accurate
characterization of your statements. Assuming that it is...

I disagree with your analysis for these reasons:

1. You can always use the JSON value container as the archive with
Boost.Serialization.
2. Skipping the value container and archiving from a JSON using a
token-based parser may be more efficient, but it is dependent on the
order of keys and thus can no longer be considered JSON, despite
having the same syntax.
3. It remains to be proven that a token-based parser which inverts the
flow of control is as efficient. If you would like to add support for
measuring Trial.Protocol in the "bench" program of my library, I would
be happy to see the results.

> That is an incorrect claim.

And yet you provided evidence to support my claim - the recent changes
you made to your code require buffering partial inputs.

However, we are getting lost in the weeds of parsing. Generally
speaking, parsing and serialization are the least interesting aspects
of a protocol library. This is true for HTTP, WebSocket, JSON, and
URLs. The important part is the container, because this is what
appears in public interfaces. For example, check out this library:

https://github.com/pokowaka/jwt-cpp/blob/b1db67e54f01f72c914af82aaea9a8d49d6dc6b9/src/include/jwt/jwt.h#L104

It implements something used for OAuth2. Note that they currently use
nlohmann's JSON. Instead, they should be using `boost::json::value`,
the type from my library, because it is more suited as a vocabulary
type.

If users are clamoring for a parser that returns individual tokens,
there is no impediment to providing one as an additional parser, in a
separate Boost library. However, I do not hear those calls from very
many folks at all (just you and Vinicius if I am being honest).

In the meanwhile, people have a very real and very pressing need for
exactly the set of features that my library offers, which is to parse
JSON into a container, inspect it and modify it, and then serialize it
back out. This is the foundation of practically every REST client and
REST server endpoint (think JSON-RPC). Now that Boost has Beast, a
solid JSON library which optimizes for the network use-case is
obviously something that Boost needs.

You said that there is "limited" utility for this use-case but I
strongly disagree. I get questions all the time about how to use the
Beast message container with a JSON payload. For example:

<https://github.com/pokowaka/jwt-cpp/issues/43#issuecomment-559291355>

Thanks