Currently, this libraries since #21 has been using async-std to spawn new tasks.
We could instead offer the task executor to be configurable using cargo feature selectors. There is the https://github.com/bastion-rs/agnostik crate to help with this.
This would let the code to be also used on Tokio or Bastions codebases (preferring using async-std or smol by default, given that we still make use of async-std::RwLock on other stuff.
I have no idea what a proactive IO framework is as well - but it would be worth checking if it make sense to use (https://github.com/vertexclique/nuclei)
Given that colmeia-hyperswarm-mdns crate is using my own custon multicast-socket crate, it would not benefit from async-std's epoll io or bastion-rs/nuclei. The replicator crate would be the next one that need to find a good io replicator.
TODO on a livestream:
Investigation:
Currently, this libraries since #21 has been using
async-stdto spawn new tasks.We could instead offer the task executor to be configurable using cargo feature selectors. There is the https://github.com/bastion-rs/agnostik crate to help with this.
This would let the code to be also used on Tokio or Bastions codebases (preferring using
async-stdorsmolby default, given that we still make use ofasync-std::RwLockon other stuff.I have no idea what a proactive IO framework is as well - but it would be worth checking if it make sense to use (https://github.com/vertexclique/nuclei)
Given that
colmeia-hyperswarm-mdnscrate is using my own custonmulticast-socketcrate, it would not benefit from async-std's epoll io or bastion-rs/nuclei. The replicator crate would be the next one that need to find a good io replicator.TODO on a livestream:
Investigation:
async-std::sync::RwLockso we can leave it as an optional dependency - https://crates.io/crates/async-rwlock https://crates.io/crates/futures-locks