Subject: Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-07-02 15:55:59
>> So why are you forcing end users to drag in ASIO?
> Beast will be part of Boost, whose distributions include Asio. To use
> serializer or basic_parser, the header <boost/asio/buffer.hpp> must
> be included, which is a pretty self-contained file. This is a
> temporary situation until Boost.Asio is updated to N4588.
If the dependency is so limited, then remove it entirely and split Beast
into non-ASIO and ASIO parts.
Most of Beast is a structured data utility library focused on HTTP. If
you made the parser capable of discontiguous input (iterator input) and
it could handle more gracefully partial/incomplete input than it
currently does, I would think it pretty much ideal and a superb
foundation for everything HTTP related for all possible end users.
>> Very little in your library has, or ought to have, anything to do with i/o.
>> Stop thinking in terms of i/o. HTTP is just structured data. So treat it
>> as such. Parse as structured data, generate as structured data.
> Is my understanding correct that you say Beast should not provide
> functions to send and receiving HTTP messages using Asio streams?
Absolutely correct. A highly reusable and flexible Beast would have a
design where knowledge of ASIO is unimportant. A second, separate
library can then combine the generic, reusable Beast stuff with ASIO to
implement lots of useful things like WebSockets etc. Separate the
concerns, decouple implementation.
I would imagine you have three design choices there:
1. Stop short of i/o, and instead provide source iterator pairs from
which ASIO (or anything else) can construct a gather buffer sequence via
boost::make_iterator_range() which is how you tell ASIO to borrow
instead of copy a gather buffer sequence. It is on the end user to pump
any state machine or sequence or reactor.
2. Provide a "tick function" for any reactor in use by the user to pump
HTTP. Study the Qt networking framework as a comparator to ASIO (it's
3. Provide a generic method of wrapping some arbitrary third party
networking implementation, so Beast provides async_read(), async_write()
etc as now, the HTTP layer does its thing, and the underlying i/o
implementation gets called eventually. The classic - if ugly -
implementation of this is OpenSSL via its BIO mechanism. You can do far
better in C++ 11.
Me, personally speaking, I would favour option 1. It's the least work,
most flexible for end users with whatever weird i/o transport they might
be using, and seems most in keeping with the overall library design
philosophy of minimal but powerful abstraction.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk