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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-07-03 15:16:07

>> Generally I've kept a headers() collection and a body() collection.
> 
> Words are cheap. Please provide a serializer which compiles and runs,
> with tests, and operates on Beast messages and does not use
> <boost/asio/buffer.hpp>. I've provided something that works, time for
> you to do the same.

That's not how Boost reviews work Vinnie.

We each provide observations, comments, questions and proposals of
alternatives. We discuss. We may each provide formal reviews.

The review manager considers all of the discussion, and provides a
judgement. So I don't need to convince *you* of anything. I need to
convince everybody else on boost-dev, and thence Michael. It's a bonus
to convince you too, but it's not a requirement.

I think there is a great library lurking in Beast, and you've done a
great job bringing us a HTTP library for C++ that is far better than any
I've seen yet. But I think some more chiselling is yet needed to hew it out.

In particular, I think it's not consistently low level enough yet, and I
think a View + Ranges API design for the bottom layer makes a lot more
sense, with additional higher level ASIO-dependent layers laid on top.
If they others disagree with this opinion, they'll (usually silently)
ignore it. If they don't understand it, they'll ask for clarification.
If they agree, they'll formally vote the same way or similarly. That's
how reviews work.

(It's also very possible that another reviewer blows a big hole in my
alternative design as having a showstopper design fault, and I thus
change *my* opinion. You might consider taking this dialectical approach
of proving why my ideas can't work rather than challenging people to
write alternative implementations. If I had the spare time to do that,
I'd have written a HTTP library a long time ago and brought it here for
review. So would many others on here who have far more experience in
HTTP than either you or I, and if properly resourced, could have made
the definitive implementation bar none)

Niall

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