Re: Jason is getting MARRIED!

From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2019-11-30 22:01:25

Em sáb., 30 de nov. de 2019 às 13:56, Vinnie Falco via Boost <
boost_at_[hidden]> escreveu:

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

If you don't care about the design of the parser interface, why are you
even exposing it outside of a detail namespace?

I've been using the older pull-based library for a few years. For my
use-case, there are a few services who consume JSON values. For these
consumers, we can classify the consumption into two categories:

* The JSON needs to be processed and forwarded further.
* The JSON is consumed at that end.

For the first use-case, a DOM interface works great.

For the second use-case, putting the JSON in a tree would be a waste. There
are a few notes that I'd like share from my experience with a JSON pull
parser:

* Matching and decoding are done in separate steps. This means I simply
skip string fields that I don't need. These fields that I don't need don't
imply constructing a new string to unescape/decode special sequences into
raw strings (for field keys I can even consume just the literal if it's
okay to violate the principle of "be liberal in what you accept").
* Returning one token at a time is not that interesting. The interesting
bit is that I'm not robbed of the control flow. I can build functions that
parse the current point from the reader. These functions won't consume one
token. These functions may consume a group of tokens (e.g. objects) and
return a single C++ value. These interfaces are composable.
* Algorithms can be built around the pull parser interface. As an example,
there is partial::skip() and partial::parse() already on the repo. The
first will skip the current element (e.g. one token for integers and a
group of tokens for objects). The latter will parse the pointed subtree
into a DOM object.
* My messages have a common part with stuff such as timestamp which are
common to all messages. My consume-loop for specialized parsers can just
forward the elements they don't know how to deal with to a common class
that fills the common fields.

If you only see the DOM container as "consumable" and "useful to expose in
a public interface", maybe it is because you haven chosen the SAX approach.

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

You haven't heard about it from very many folks. Then you came here for
feedback just to argue the feedback is irrelevant. If you're not interested
in feedback, why even post on the mailing list? I'm glad I'm not developing
a JSON library because the rushed way you try to make this into wouldn't be
the most pleasant experience to deal with (and we better match your time
constraints to answer).

In the meanwhile, people have a very real and very pressing need

Boost is no place to pressing libraries to be delivered on a timeline.
These people who need a library today can use any library on the market.
C++ sucks to include new libraries in your project, and some may see in
Boost a place where they can install a bunch of libraries at once, but
that's not what Boost is about. Boost is about peer-reviewed high-quality
libraries. If one library is not ready, it goes back to the design phase. A
library will be ready when it's ready.

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

Waste no time defending this view. This view is not being challenged.
Nobody is arguing against a DOM object as far as I can tell. Backing down
to defend the DOM object makes no case to the more heated object under
discussion.

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

Trial.Protocol also has a DOM object. Bjørn obviously also sees value in
such container then. That's not what's under heated debate.

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/