Re: [boost] [beast] Request for Discussion

Subject: Re: [boost] [beast] Request for Discussion
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-09-27 07:39:23

On 25 Sep 2016 at 8:26, Vinnie Falco wrote:

> On Sun, Sep 25, 2016 at 7:01 AM, Bjorn Reese <breese_at_[hidden]> wrote:
> > ...I initially suggested that you and Vinicius collaborated instead
> > of seeing your respective libraries as competitors.
> 
> Absolutely, which is why I reached out to you and Vinicius in April.
> Me and Vinicius spent several hours talking about our respective
> libraries on Skype. I reported back to the group on this:
> http://lists.boost.org/Archives/boost/2016/04/229337.php
> 
> I noted that Boost.Http and Beast had minimal overlap. Beast provides
> low level HTTP protocol functionality while Boost.Http offers a
> turn-key HTTP server. From that discussion came some action items, I
> made changes to the Beast message model. I delivered a header-only
> parser with no dependencies on the rest of Beast so it could be
> re-used in Boost.Http, and informed Vinicius. I started a discussion
> on further refinements to the message model
> (https://github.com/vinniefalco/Beast/issues/13). I have seen no
> evidence of Beast integration in Boost.Http.

My thanks to Bjorn for raising the GSoC point. I should clarify that 
whilst a unified library would be preferred by all, in the end there 
is nothing stopping BOTH libraries entering Boost even if they cover 
similar ground.

By the way, Bjorn is one of those here on boost-dev whose feedback on 
a HTTP library I would weigh very heavily in any peer review. Bjorn 
knows his stuff here, and as he mentioned, he would be highly likely 
to write a very high quality HTTP library on his first attempt had he 
the time to do so.

Regarding persuading Vinicius to use Beast in Http, it's not like 
anyone can wave a magic wand here. Plenty Boost library authors 
refuse to use other Boost libraries and instead reinvent the wheel. 
The deliberate and intentional refusal to reuse existing library code 
is taken into consideration during any peer review, and I have noted 
it has generally not been weighed heavily when deciding to accept.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/