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

On 02/07/2017 18:25, Vinnie Falco wrote:

On Sun, Jul 2, 2017 at 9:07 AM, Niall Douglas via Boost wrote:

...

Ok, Vinnie. Enough of the aggression. ... If you don't want my feedback because of some grudge against me, say so

There's no grudge but this is what I'm hearing:

"Beast should not perform socket I/O."

I don't know if its your style of speaking, or word choice but this feedback is patently absurd on the face of it.

I don't see the absurdity at all. Let me give you some background. I've implemented basic HTTP perhaps six times now in my career to date. Four times in C/C++, twice in Python. I don't have the depth of knowledge of full fat HTTP like say Bjorn does, seeing as he contributed extensively to curl, but I've implemented this stuff lots of times now. And how you've designed Beast is close to my earlier HTTP implementations, and far from my later HTTP implementations. This is why I keep asking about your fundamental design assumptions. I think you evolved your design starting from the assumption of socket i/o, when you should have started from blobs of structured data in, blobs of structured data out. I know for a fact that's suboptimal because I've been there before too.

So you think users shouldn't be able to implement a web server or HTTP client using Beast? How does one even begin to respond to that?

Your userbase to date suffers from selection bias. They want something which works with ASIO, so they use Beast because it ticks that box. I can assure you that for every user you have gained to date, you lost at least two, maybe three users who looked at that ASIO dependency and thought "god no, not worth the hassle" because they also know how painful it is to get a custom socket implementation to work with ASIO. I also know that you'll never, ever encompass all the weird data transports your full potential user base will have. All sorts of weird custom, often proprietary things. So free your library of the ASIO dependency. You don't need it, indeed it's damaging you. Design your library to work with any unknown transport instead. For example, switched banks of reference counted shared memory with the current one selected by a std::atomic. Blobs of structured data in, blobs of structured data out - that's your only requirement. As I've mentioned on list now several times, ASIO readily will consume any custom gather buffer sequence type: simply specialise the appropriate ASIO free functions and traits and you can feed it beast::const_raw_buffer which is a const char * and a size_t (or still better, a span<const char> or a string_view). So your library's users can #include or something and thereafter directly feed Beast scatter-gather buffer sequences to ASIO. Or they can for loop them into an array of struct iovec and call the equivalent of writev() on whatever weird custom transport they are using. Point is, you need to be _facilitating_ i/o, not _implementing_ i/o.

I'm going to push back considerably on statements of the form "your library shouldn't do what it does" such as yours.

I think your library should focus on making HTTP easy for everybody with a need for HTTP. Do one thing really well, it's where Boost.Http fell down.

I want to give you the benefit of the doubt, maybe you're trying to say something else such as, the library should be presented as two separate libraries? But that's not how it sounds.

BTW, just so you know, I'm currently on a conditional accept with a low confidence interval. It's why I'm interrogating your fundamental design choices: as much as the _correct_ HTTP library design allows things like switched banks of shared memory as the transport, such flexibility is not _necessary_ for a HTTP implementation. And where I am stuck is on what weighting to give these imperatives, you must remember it's not just you and me going back and forth. Lots of other people are likely as stuck on this as me and are reading everything on boost-dev. So your justifications of design choice to me, and persuasion that your choices are not showstoppers, are what gets a library accepted. After all I'm definitely not the only person who has implemented HTTP half a dozen times, and is likely looking at your library and wondering about the design assumptions too. It's just they haven't said it yet because our dialogue was answering their questions. So even if you and me stop, you may well see the exact same themes - though perhaps more tactfully put than from I - being raised anyway. I particularly strongly weigh Bjorn's opinion, we used to work at the same employer for a bit where we developed a replacement for TCP extending ASIO, and where HTTP was going to be deployed over that. Interestingly Beast would likely have worked just fine on that as it was ASIO based, but we very nearly didn't choose ASIO as the base, in which case Beast would have been useless to us. So if he greenlights you, I'm happy, if not, then you should take the feedback he gives you very seriously. He really knows his stuff. Niall