Boost logo

Boost :

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
pretty similar).

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at