Boost logo

Boost :

Subject: Re: [boost] Push/pull parsers & coroutines (Was: Boost.HTTPKit, a new library from the makers of Beast!)
From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2018-01-01 21:28:59

2017-10-13 16:24 GMT-03:00 Vinnie Falco via Boost <boost_at_[hidden]>:

> <
> 57b1bf889568cf27c39f/include/boost/beast/http/parser.hpp#L45>
> Callbacks don't need to store state used by subsequent callbacks to
> interpret the incoming structured HTTP data, because HTTP is simple
> compared to XML or HTML.


Indeed, there is no need to store state to interpret incoming structured
HTTP data, but we still may need to store state between one call and
another. This was just the case in the previous example I gave you.

Given the nature of the project Tufão using Qt, I have this thing called
"safe signals":

This safe signal of mine forbid me to access the object after I emit a
signal. So I have to parse the whole received data before emitting any
signal. What happens is... in the example I gave earlier, Boost.Beast
parser will force me to have state inside the object itself:

If you compare to the usage of Boost.Http parser, it's different:
4a142dea9a/src/httpserverrequest.cpp#L135 (a local variable that only
exists when it needs to)

You should be more humble[1] about the user needs and wants or you'll limit
the potential usefulness of your library.

Therefore, when designing an HTTP parser we can place
> less emphasis on the style of parser and instead focus those energies
> to other considerations

My project Tufão couldn't care less about the other stuff you grab from
ASIO that you're trying to convert into the focus of the discussion. It's a
Qt project and Qt networking is used. That's just the motivation for your
separate submission (as users requested abstractions to parse HTTP without
ASIO from the review comments). And I still find disappointing that I still
need to show specific/concrete cases.


Vinícius dos Santos Oliveira

Boost list run by bdawes at, gregod at, cpdaniel at, john at