Async API

[Congyuwang]

struson is good for a lot of internet applications. So, async stream writer would be nice to have.

[Marcono1234]

Thanks for the suggestion! That is a good point.

Unfortunately it seems to be difficult at the moment to support both sync and async code without duplicating code or running into other issues. See this very extensive blog post and the corresponding discussion on Reddit¹.

For now I was hoping to wait for "maybe-async", in case that is ever implemented.

But this suggestion is definitely valid, so I will keep this issue here open.

In case it is helpful, it looks like @hdoordt converted the API to async in their fork: https://github.com/hdoordt/struson/commits/async-read-write/
But I am not sure if this was a one-off effort, or if he is planning to maintain it in the future. (Either way, thanks hdoordt for considering Struson in the first place!)

Footnotes

1. Though please correct me if I overlooked something, or if that information is outdated. ↩

[Congyuwang]

You've made a good point. I realized that maybe for the moment, that really means to maintain another repository, and would mean quite a bit more work. Thanks though.

[hdoordt]

@Marcono1234 Thanks for the reference. My fork is mostly meant for demonstrating, and figuring out whether something like maybe-async makes sense for struson.

My conclusion would be that it's not exactly trivial, but it's not that hard to do either. It's possible to do something like that with macros today, and while I'm not entirely happy by the results you'd get from something like that, it more or less boils down to a bit of plumbing

[Marcono1234]

and figuring out whether something like maybe-async makes sense for struson

Do you mean https://github.com/fMeow/maybe-async-rs? I will probably not use that due to fMeow/maybe-async-rs#6, since it is conceivable that users could end up with a sync and async version of Struson in their transitive dependencies, which would break their build.

In the comments there are proposals to instead generate separate 'sync' and 'async' modules, and there is for example also https://github.com/JM4ier/bisync. That sounds like a better solution to me (but I am not very experienced with the topic), so there could be an async module in Struson then for example which is an async copy of the API. But it looks like those crates are not that popular yet¹. And in case they become unmaintained in the future or aren't updated to work with newer Rust features, this could become a big maintenance issue for Struson.
Also, I am not sure how well they work with Rust doc comments / doc tests. So that still might need quite some work.

But maybe something to consider for the future.

Footnotes

1. Unfortunately some kind of "chicken-egg-problem" (?): Crates are not used because they are not popular, and because they are not used they don't become popular... ↩