$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-07-03 16:34:55
On Mon, Jul 3, 2017 at 6:19 AM, Paul A. Bristow via Boost <
boost_at_[hidden]> wrote:
> > I think that makes sense in a high level HTTP library. For a low level
> > HTTP library I think it a design mistake, much simpler is much better.
> > Less is more. I've used the above serialiser design on a number of
> > occasions now, it's very efficient, composable, and flexible. It *does*
> > push understanding of HTTP onto the end user, but then if the end user
> > doesn't understand HTTP, they wouldn't be able to use a low level
> > library anyway.
>
> If BEAST is accepted, is there any reason why such an even--lower-level
> library could not (or should not) be written (and also
> accepted)?
>
I don't see why not. For example I think it was a mistake to reject Synapse
on the basis of "we have a signal library in Boost already", because there
is literally nothing in common between it and Boost Signal, except that the
latter can be used in a subset of the cases where Synapse can be used.
If we reject a library it should be on its own merits, not on the merits of
another library, except if the differences are trivial.