On Fri, Aug 15, 2025 at 1:41 PM Vinícius dos Santos Oliveira < vini.ipsmaker@gmail.com> wrote:
If it's going to be a new library with a new design, it should go through the Boost peer review process.
Yes to the review process, which is why I am first gauging interest. As for the "new design," I am not looking to innovate here. The fork would use the same interface principles as Asio and the same code, except for things that we want to modernize which would not be accepted in original Asio. The canonical example being the use of `std::error_code`. Where we would differ is that there could be support for things that Asio won't do, such as native Botan support for TLS. Or this WolfSSL which is alluded to in the neglected GitHub issue in the OP. I don't know if your idea is going to be sufficiently different to warrant
a new library that's mostly going to be an overlap of what Boost.Asio already does though.
I'm not sure it needs to be sufficiently different, other than having responsive developers and active support. This is why I am posting to the mailing list. Would a fork of Asio which keeps mostly the same interface, has enhancements desired by the community, and has updated documentation and ongoing support worth having as a Boost library?
I'll chime in later with more points. In the meantime, is it my impression or am I the only person who still uses the mailing list asio-users? What should be the alternative for asio-users?
Is asio-users a Boost mailing list? I don't use it. Given the decline in mailing list participation, I think we should try to consolidate all of our mailing list activity down to just a single mailing list (the developer's mailing list). The volume of user traffic is so low, that we should not complain about answering user questions in the developer mailing list. Robust technical discussion is the lifeblood of the Boost library collection and we need to nourish it. Thanks