Provide async API
zeenix opened this issue · comments
Since it's an IPC API, it should be async. Moreover, I think async should be the primary/main API, with blocking wrappers on top.
I understand this is going to be a major change/break but given that currently this crate has not many users, I think that shouldn't be a concern. It'll involve bumping the major number of course.
The real problem (apart from this being a big project), is going to be implementing an async runtime-agnostic solution. The bad news is that there is no good solution for this (for now). The good news is that I've dealt with this problem in zbus and we've a not-so-bad solution now: be runtime agnostic by default using smol-rs crates and providing tight integration with tokio (through an optional feature).
It might be possible to reuse some or all of the abstractions we've in zbus for this.
@haraldh seems you already thought about this some years back and your thinking was to use use tokio. Although that would alienate many folks who don't or can't use tokio but it does certainly makes the task much easier.
I'll accept all PRs which add a solution to this problem :)
I'll accept all PRs which add a solution to this problem :)
Cool. It may or may not be me, depending on if I can possibly get some paid time to work on this. :) I just wanted to create the issue with some pointers on possible approaches.
This looks interesting https://www.firezone.dev/blog/sans-io