Re: [beast] Review

Subject: Re: [beast] Review
From: Marcel Ebmer (marcel_at_[hidden])
Date: 2017-07-07 10:37:08

On 07/05/2017 04:13 PM, Vinnie Falco wrote:
>> WebSocket control frames are automagically responded to. Iff there's an
>> active read(). Basically, having an active read() at almost all times is a
>> requirement of any correct program using Beast. Even though I enjoy the
>> help from the library, and the requirement is usually met, I found this
>> specific behaviour to be inconsequent.
> What's the call to action? What change is being proposed?
I don't have a concrete proposal. What I was trying to describe is the
discrepancy between the general look and feel of the library - where the
user is in full control, and hence bears full responsibility - and the
automagic happening with WebSocket control frames. And, to make it feel
even more awkward, the automagic is actually semi-automatic. I realize
there's probably no sane way to have control frames always responded to
during the lifetime of a websocket::stream. It may, however, be
reasonable to give control back to the user and just provide convenient
utilities for sending the appropriate responses.
> "out of scope": that dreaded phrase that no one wants to hear :)
>
> The features you described are arbitrary. Why forms and not basic
> authentication? Why URL decoding but not a full URI parser? Why a full
> URI parser but no handling for redirects? What about supporting
> proxies? Anything that I add is going to satisfy some users and
> disappoint others.
I don't agree. Any feature you add will satisfy some users, and
not-yet-satisfy others. Big difference.
> That doesn't mean that I won't be building new higher level features
> (I'm already working on a URL decoder) but I think they belong in a
> separate library with its own documentation, tests, CI infrastructure,
> and also separate Boost formal review process. Still, there's only so
> much I can do - HTTP is a MASSIVE domain!. The only reason I was able
> to get Beast to where it is at was by being strict on what features I
> would support.
For a new library, the expectations would be very high. It would have to
support all of HTTP - which may well mean that such a swiss army knife
library will never happen. For an existing library, like Beast, the
level of expectation (concerning new features) is a lot more bearable.
Anything you give us will be seen as a goodie. Beast CAN add an URI
parser without supporting Basic Authentification. Or Basic Auth without
supporting form data at the same time. You could also put the
functionality into a utility namespace and exclude that from your
standards proposal.