Bjorn Reese wrote:
On 2020-09-22 14:20, Peter Dimov via Boost wrote:
I don't think so. In fact the reverse is true. Deserialization from DOM is trivial. Making a deserialization library build a DOM is decidedly nontrivial. I'm not sure how it could be done.
It is easy with a pull parser. The following header shows both direct serialization from DOM to JSON, and direct deserizalization from JSON to DOM:
https://github.com/breese/trial.protocol/blob/develop/include/trial/protocol...
Yes, you're right, it's indeed easy with a pull parser, if the value and the archive cooperate. This still doesn't make one approach a superset of the other though. You can feed Boost.JSON's push parser incrementally. A pull parser, being a pull one, reverses the flow of control and asks you (its stream) for data when you pull from it. Yes, it makes things like the above possible, but I don't think it entirely supersedes pull parsers. I remember this being brought up before, so you may have a solution for the incremental case. A pull parser could f.ex. return token::need_input or something like that when it's starved, like a nonblocking socket. There'll still be a disconnect between its buffer size and the amount of incoming data though, unless I'm missing something.