On Sat, Nov 30, 2019 at 7:33 AM Bjorn Reese via Boost
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/b1db67e54f01f72c914af82aaea9a8d49d6... 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