|
Boost : |
Subject: Re: [boost] [beast] Request for Discussion
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2016-10-02 11:08:49
On Sun, Oct 2, 2016 at 10:31 AM, Bjorn Reese <breese_at_[hidden]> wrote:
> Looking briefly at your HTTP parser I can see that it is a push parser,
> which may serve your current purposes, but not those of higher-level
> use cases.
Beast offers parsing free functions that are not advertised loudly
(because they are more complicated to use, but give callers more
control):
http://vinniefalco.github.io/beast/beast/ref/http__parse.html
http://vinniefalco.github.io/beast/beast/ref/http__async_parse.html
These functions accept any object meeting the Parser type requirements:
http://vinniefalco.github.io/beast/beast/ref/Parser.html
Although, this interface might still have as an unstated requirement,
that such a parser must be of the "push" variety.
I did some Internet searching about push versus pull parsing, both now
and a bit ago when there was chatter about Boost.Http adopting a pull
parser. All I could find was push versus pull parsing in the context
of processing XML and HTML content. I was unable to find anything
having to do with pull parsing and HTTP, with the exception of some
Rust code:
https://github.com/vinipsmaker/http-pull-parser-rs
I'm having a difficult time understanding how a pull parser would be
suitable for an algorithm that can operate on a network socket -
perhaps you can enlighten me?
> The purpose of the BSoC project was to investigate the more flexible
> design of pull parsers that extends more easily to higher-level
> interfaces.
I'm very interested in hearing about these higher-level use cases. Is
there a discussion or some kind of example that I can study? Or can
you provide more details? If there's some sort of design flaw in Beast
that prevents users from important implementations, I would like to
find out and address it.
Regards
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk