On Sun, Jul 2, 2017 at 5:16 AM, Bjorn Reese via Boost
The HTTP API provides a set of free function for all operations, so all interaction follows this pattern:
operation(socket, args);
The WebSocket API wraps an Asio socket in a stream, so all operations are like this:
stream.operation(args);
I realize that the latter choice is a consequence of using SSL, but I am wondering why there is no socket.operation(args) style for the former?
The question is, why does HTTP use beast::http::read(socket, buffer, parser); while WebSocket uses: ws.read(buffer); Its not really related to SSL but rather, reflects the fact that WebSocket connections are stateful. The beast::websocket::stream maintains information needed in between calls to read and write. For example there are user defined options, the control callback, the permessage-deflate state, and various control structures needed to "park" composed operations to give callers the illusion that read, write, ping/pong, and close operations can be performed concurrently. These have to be stored in an object associated with the lifetime of the connection: https://github.com/vinniefalco/Beast/blob/78a065ba39836d91d7e70d93de7f9140f5... I thought about having a beast::http::stream<> wrapper for HTTP/1 (its definitely needed for HTTP/2) but what would go in it? You could maybe put a parser in there. But in order to choose a Body type based on the request header you need to select the Body type at runtime. Affixing a parser to an HTTP "stream" wouldn't allow that use case. So there's really no state to be maintained. Therefore, Beast opts for HTTP free functions since that is the most simple and straightforward solution. Thanks