Re: Jason is getting MARRIED!

From: Bjorn Reese (breese_at_[hidden])
Date: 2019-12-08 15:21:37

On 2019-11-30 17:55, Vinnie Falco wrote:

> When you say "excludes Boost.Serialization style serialization" I
> believe you are referring only to the Parser in the list above.

Not really. I am refering to the ability to create Boost.Serialization
input and output archives.

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

The whole point of Boost.Serialization is to not go though an
intermediate DOM, but to parse the data directly into the data
structures provided by the user.

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

This argument makes no sense at all.

Firstly, JSON Object is unordered, so any key permutation is a valid
syntax. ECMA-404 is quite explicit about this.

Secondly, the json::reader and json::writer processors do not change
the order of key-value pair. If the data structure used by the user
preserves the order, then so will the serialization.

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

I do not see how that follows.

I made a single change to the json::reader class in order to support
chunked parsing. This had no performance degradations.

I also added a simple _example_ to show how chunked parsing can be done,
and I even stated that this example could be optimized. However, putting
optimized code in examples tends to obscure the purpose of the example.

There is really nothing that confirms your claim.

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

This is an odd argument to raise here given that Trial.Protocol also
has a vocabulary type, as well as DOM parsing/formatting.

> 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

I am saying that your JSON library supports less use-case than
Trial.Protocol. Whether or not that is sufficient is a subjective
judgment.