On Mon, Jul 3, 2017 at 6:19 AM, Paul A. Bristow via Boost < boost@lists.boost.org> 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.