Re: Jason is getting MARRIED!

From: Bjorn Reese (breese_at_[hidden])
Date: 2019-11-30 15:32:55

On 2019-11-24 16:30, Vinnie Falco wrote:

> I'm not seeing where trial.protocol has incremental algorithms,
> perhaps you can show me? trial::protocol::json::basic_reader
> constructs with the complete input:

You are right. Chunked parsing was missing. The json::reader is a low
level API that does not manage buffers, but it does indeed lack a
function for updating the view without resetting the other state
(the nesting levels.) Fortunately that is a trivial change, which
I have just added for your pleasure, along with an example of chunked
parsing that is akin to yours:

 
https://github.com/breese/trial.protocol/commit/681afed05f32eb5288d6703d553783dfd917aeae

Buffer management can obviously be optimized in the example.

> I disagree. Again the central premise here is that there is no ideal
> JSON library which can suit all needs. I believe this is why Boost
> does not yet have a JSON library. Optimizing one use-case necessarily

Maybe there is no single JSON library that suits all needs. However,
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.

> comes at the expense of others. At the very least, the inversion of
> the flow of control (i.e. a parser which returns a token at a time)
> advantages one use case and disadvantages others (such as working as
> an online algorithm). There are other tradeoffs. Because my library

That is an incorrect claim. Both push and pull parsers needs to parse
tokens one by one and keep state information. You do not have to take
my word for it; here is what Thiago Macieira had to say about it:

   "First of all, the type information is there anyway. The only
    difference is whether it is exposed to the user in the API or whether
    it's hidden. In the SAX case, because of the push-style API, it's
    hidden and the parser does the switching for you and calls your
    function.

    Second, you must provide something like an iterator anyway if you
    want to provide some type properties to the visited function.
    Properties like array size, string length, etc. That is required if
    you want to implement string zero-copy.

    [...]

    Mark my words: the SAX parser will be implemented on top of the StAX
    one."

 From 
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/JNZzOvC7llo/l1DVhKBtCwAJ

And just confirm his "mark my works" comment, this is how simple it is
to create a push parser with a pull parser:

 
https://github.com/breese/trial.protocol/blob/develop/example/json/push_parser/push_parser.hpp