Hi, this is my Capy/Corosio review.
1. What is your evaluation of the usefulness of the libraries?
From Corosio point of view I think there is no need to elaborate. A networking library is immensely useful. The Capy library provides ground for sans-io protocol libraries, which is fundamental for testability. I am not sure whether it is the best option from the performance point of view (as discussed in another thread) but that is only possible to evaluate once more libraries are built on top of it. Boost is the correct place for such experiments though.
2. What is your evaluation of the design?
It has addressed many of the problems we encounter when developing libs on top of Asio - capy::any_stream: In Asio it is burdensome to write a connection type that works with both plain and secure connections i.e. pass either stream or stream.next_layer(). Capy any_stream simplifies this. - Type erasure. In Capy I don't have to think about type erasure whereas in Asio I need any_io_executor and any_completion_handler. - In Boost.Redis we offer basic_connection<Executor> and connection (ype-erased), whereas the Capy-based Boost.Redis has only one connection type i.e. co_connection. That is a big win for users. - By being a coroutine from the ground up it does not need the completion token model from Asio and achieves much faster compilation times. This is again a big win. - More async primitives e.g. capy::async_event. I have to investigate more but this might be related to the performance improvements I have observed in my benchmark report.
3. What is your evaluation of the implementation?
I haven't looked at the implementation but it seems reliable. As Ruben already pointed out, the Boost.Redis port to Corosio passes tests and has impressive performance. No concerns here.
4. What is your evaluation of the documentation?
It is very good although I think it often contains too many words.
5. Have you used either or both libraries? What was your experience?
I wrote a performance benchmark using corosio https://github.com/mzimbres/redis-cli-comp/blob/main/apps/boost-redis/app_bo... and was happy I did not have to type async_ prefixes anymore :) There is no friction for users with Asio experience.
6. Are the libraries ready for inclusion in Boost?
Yes. It is the correct time to let it mature in Boost and gain more feedback.
8. Do the libraries fit well within the existing Boost ecosystem?
Yes, but it is important to notice that Corosio competes with Asio and increases the ecosystem fragmentation. This is not a Capy/Corosio fault and there is precedent for competing libraries in Boost, but it really hurts the overall C++ software quality, for example, when your http client uses one net lib, the database driver another and so on. Perhaps soon there will be a senders and receiver based net lib. Libraries aren't likely to support all net variations natively and interop will be more likely.
9. Are there API, naming, usability, extensibility, or implementation concerns that should be addressed?
I vote ACCEPT. Thanks, Marcelo