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

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

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