On 7/07/2017 11:49, Vinnie Falco wrote:
On Thu, Jul 6, 2017 at 4:23 PM, Gavin Lambert wrote:
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.
Ah! I see the confusion now. Both HTTP and WebSocket in Beast operate on stream algorithms. However, a WebSocket session has state whose lifetime must be managed. HTTP/1 does not. Beast's interface for HTTP operations uses simple free functions, while the WebSocket interface uses a different approach. It offers a wrapper which wraps your SyncStream or AsyncStream. Depending on how you declare the wrapper, it is either a non-owning reference, or an owning wrapper.
Ah, thank you, that resolves my concern.
Although HTTP/1 is stateless, HTTP/2 is not. When Beast gains an HTTP/2 implementation (a planned feature) it will use the same wrapper style as websocket:
If you know that this will be required in future, then why not use that same style for HTTP/1 today? It might not be necessary but it ensures a consistent interface (and it leaves you open to possibly storing some state if it turns out to be necessary for some other future HTTP/1 extension).