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.