Boost logo

Boost :

Subject: Re: [boost] [review][beast] Five-days Remaining
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-07-06 23:23:46

On 6/07/2017 19:24, Vinnie Falco wrote:
> On Wed, Jul 5, 2017 at 11:51 PM, Gavin Lambert wrote:
>> it seems like the HTTP part is focused on simply parsing and generating the
>> HTTP message format (and thus conceptually could do so with any stream
>> abstraction, including a non-socket-based one)
> Against which yet-unspecified stream abstraction do you feel Beast's
> algorithms should be written? The rationale for the current choice of
> using Boost.Asio's stream abstractions is explained here here:
> <>

I said that being based on a *stream* abstraction is a good thing. As
that is lower-level than a *socket* abstraction, and could be used on
other streams that aren't sockets (eg. a non-socket-based networking
library on some other platform, or for simulated conversations in unit

I somewhat agree with Niall's point that fundamentally this doesn't even
need to be based on streams and it could be based on byte blob
containers instead, but since in practical use it will most likely be
used with streams anyway and using blob containers as the basic
interface could lead to unnecessary copies, I think using streams was
the right call.

And if you're looking for a stream abstraction, it's hard to beat
Asio's, so that was also a good call.

>> but then the WebSocket part goes beyond that to include actual socket
>> management and connection lifetimes.
> Which socket and connection lifetime management features are you referring to?

The HTTP code acts on streams. The WebSocket code acts on sockets, not
streams. (Evidence: nowhere in the HTTP docs could I find a method that
used anything other than an abstract stream as a parameter. Whereas in
the WebSocket docs the very first thing talks about handing over
ownership of a socket to the WebSocket stream class, and this is the
basis for everything else.) This is clearly a higher level than the
HTTP code.

Maybe there's some technical benefit to having this in one library
rather than being split into two, but then that should probably be
explained in the design choices.

What I was suggesting is that the WebSocket parsing and formatting code
be kept in Beast (eg. the code that generates the byte blob that
represents a frame; as this would be stateless stream-based similar to
the HTTP code) but the part that deals with sockets should be split to a
separate library Beast.WebSocket (or whatever).

Otherwise the design seems a bit inconsistent -- it's low-level except
for websockets.

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