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... ↩

[Friz64]

I quickly hacked together something for my purposes that makes this library compatible with embedded-io-async: https://github.com/Friz64/struson/tree/embedded-async

I threw away the serializing and serde features because I didn't need them, as well as all the tests (:p). It works for my silly little project, maybe this helps someone.

[Sytten]

@Marcono1234 In general the idea is to build a "sans-IO" core and then have two implementations for async and sync IO.
For what it is worth I am trying to find a solution to stream serialize JSON to actix web streaming body, if I find a solution I will post it here.

[Marcono1234]

I quickly hacked together something for my purposes that makes this library compatible with embedded-io-async: https://github.com/Friz64/struson/tree/embedded-async

@Friz64, it seems you also changed Struson to support no_std environments. I have created #124 to track research about if Struson could properly support no_std, and how easy that would be. Feel free to share your thoughts there.

[Marcono1234]

In general the idea is to build a "sans-IO" core and then have two implementations for async and sync IO.

@Sytten, I am afraid that applying this approach for Struson would require larger implementation changes and possibly also make the implementation more complex. However, if you think it would be feasible feel free to share your ideas here (or in a separate GitHub issue or discussion). Though I am not that familiar with the sans-IO approach so I cannot make any promises whether I will end up adopting it for Struson.

In the meantime maybe an async JSON library like https://github.com/michel-kraemer/actson-rs is useful for you.