Re: [boost] [review][beast] Five-days Remaining

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:
> <http://boost.2283326.n4.nabble.com/review-beast-Review-of-Beast-starts-today-July-1-July-10-tc4696294.html#a4696441>

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 
tests).

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.