Allow other async runtimes such as async-std

[A248]

I'd like to use this library myself, but with async-std rather than Tokio -- my existing code is written against async-std.

Could async-std be supported by a feature flag? I am willing to create a PR if necessary

[john-bv]

If it can be done without changing the API or code clutter than sure.

[A248]

No, it can't be done without changing the API. The API directly links to tokio, hence why I suggested a feature flag.

I'm not sure what exactly would qualify as code clutter. It depends on how much reliance there is on tokio, and how much of that can be replaced by executor-agnostic async code.

Based on a search for tokio using Github's search feature, tokio is only used inside server.rs, which seems promising.

[A248]

To clarify: the API would change very little. Only the start method appears to be affected. Overall, there doesn't seem to be an undue reliance on tokio, which means it may be easy to add support for other runtimes.

[john-bv]

The only things that would need to be modified are the tokio tasks inside server.rs with the start method.

[john-bv]

To clarify: the API would change very little. Only the start method appears to be affected. Overall, there doesn't seem to be an undue reliance on tokio, which means it may be easy to add support for other runtimes.

Feel free to make a PR. However I'd like to mention the external API should remain relatively the same.

[john-bv]

I can make a PR in a bit adding this if you don't want to, as it could be useful in the future.

[john-bv]

I'll be including this in the "v2" (actually 1.x.x) rewrite, as it includes a lot of design improvements from master, I expect the rewrite to be done sometime this week.

[john-bv]

Okay, now that everything to my knowledge is 100% working, I will get started on this issue 😄

[john-bv]

@A248 This issue is now tracking branch v3-async-std