Em sáb., 30 de nov. de 2019 às 13:56, Vinnie Falco via Boost < boost@lists.boost.org> 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/