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.