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