Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10

Subject: Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10
From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2017-07-09 16:49:26

2017-07-08 16:51 GMT+02:00 Vinnie Falco via Boost <boost_at_[hidden]>:

> On Sat, Jul 8, 2017 at 7:19 AM, Vinícius dos Santos Oliveira via Boost
> <boost_at_[hidden]> wrote:
> > I only found the time to join the discussion now 😢
>
> Glad to see you here Vinícius! I see you've been busy working on your
> repositories (I check on them from time to time) - that's great!
>

Yep. I've been more busy with my work than my open source contributions,
but I donate time to my open repos from time to time.

> Anyway, it's fairly easy to adapt this parser model to C++ iterator model
>
> Using templated iterators (I think that's the direction you're
> implying) offers flexibility. But there are advantages when using a
> raw pointer to a contiguous piece of memory holding the entire HTTP
> header or other structured element (chunk-header, final-chunk). Such
> as using SSE4.2 intrinsics to accelerate the parsing:
>
> <https://github.com/vinniefalco/Beast/blob/6f88f0182d461e9cabe55032f966c9
> ca4f77bf46/include/beast/http/detail/basic_parser.hpp#L223>
>

Nope.

I'd point to the documentation, but I'm still writing that.

You can just look at the link I provided, it's the parser I wrote being
used on a Qt application. No problematic dependency on Asio's
executor/io_service. I agree with the “raw pointer to a contiguous piece of
memory” and that's why I use Asio's buffer abstractions (sorry Niall, but
there is no need to reinvent the wheel).

> After the review on my library, I noted there was a big interest in
> low-level control for handling HTTP messages.
>
> Can you please list the low-level control features or maybe link to
> the corresponding boost-dev posts which describe the desired low-level
> control? I thought I addressed them but I'd like to be sure
>
> Thanks

The discussion was so big and happened years ago. Can't do that. I just
wrote the summary as a list of issues to fix in my all design (so
everything which was already right is lost in the discussions of this
mailing list).

Just provide a parser better than NodeJS and you're good for the most
uncommon users. No allocations etc.

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