On Fri, Aug 15, 2025 at 6:53 PM Klemens Morgenstern via Boost < boost@lists.boost.org> wrote:
The more I read issues and PRs on asio, the more I understand Chris' policy.
Chris policy is: 1. Not to participate on the mailing list 2. Not to respond to emails 3. Not to engage in discussion with stakeholders 4. Not to respond to GitHub issues The number one portable C++ network library is often giving users a bad experience. We can do better.
Could you elaborate on what kind of evolution you would like to see.
Yes. More examples. Better documentation. Requiring newer versions of C++ and using more standard types.
Why couldn't boost.crypt just implemen It's own crypt-stream type like botan does?
It could. This doesn't solve the stated problem, which is that the Boost networking library that many other libraries depend on (Redis, MySQL, Beast, http-io, websocket-io, cobalt) has an author who is unresponsive to users, unresponsive to emails, unresponsive to the mailing list, and unresponsive to GitHub issues.
That would be design by committee. A lot of stakeholders have input through Chris being part of the industry and they would never participate in an open discussion.
Right, and the design that I am referring to has to do with cosmetic things such as which error code to use. We would not be innovating on the networking API and smarts. Instead we would track the upstream repository. We could however have more examples. Better documentation. And most importantly we could control the GitHub issues and respond to people who open the issues. Even if all of the opened issues are garbage as you imply, then we could explain why they are not actionable and actually close them. This way new visitors to the repository do not see an unmaintained project.
4. Changes in Asio would be adopted on an as-needed basis
And who determines what is needed?
We have to figure that out. Likely we would just track everything.
What do you think?
Horrible idea. Greenfield one to compete with asio and motivate chris to add them this way.
You are suggesting that we create a new networking library from scratch. In my opinion, this is foolish. Chris already did the bulk of the work, and we would be throwing that out. I do not think I can do better than Chris. And I am certain that you cannot do better than Chris. A greenfield solution would be inferior. Furthermore, based on my observations of Chris over 8+ years, he is not the kind of individual who would be "motivated to add them this way." Quite the opposite he would probably be relieved that an alternative exists and he might actually just stop maintaining the Boost version of Asio (which is not used in the HFT systems he works with). Thanks