Closed zeenix closed 1 year ago
@MaxVerevkin We thought about this before 2.0 but not sure how to do that exactly. We can use features but they're supposed to be additive, not for choosing the backend.
However, I'm planning on provide a zbus_tokio crate that provides API for constructing Connection
that's fully integrated into tokio out of the box. i-e make this work redundant.
@MaxVerevkin We thought about this before 2.0 but not sure how to do that exactly. We can use features but they're supposed to be additive, not for choosing the backend.
hmm.. on second though the discussion I'm referring to was about choosing the right I/O crate (async-io or tokio) and what you're suggesting is making async-io optional so we don't provide the Connection
constructors that assume it. The planned zbus_tokio
crate can then disable async-io
feature and re-export zbus
at the top-level.
So anyway, if could provide the MR for this, it'd be most welcome. :smile:
mentioned in commit 98c00873df55de73d2c4b4bf77a7625fd00b494b
In GitLab by @MaxVerevkin on Feb 8, 2022, 22:51
Thanks for implementing this :)
In GitLab by @MaxVerevkin on Jan 13, 2022, 17:34
Since it's possible to rely on
tokio
for asynchronous IO, I thinkasync-io
dependency should be opt-out.