Maintenance status?

[maxcountryman]

Hi there, I'm hoping to check in and see where we're at with maintaining this crate. If there's interest, I'd be happy to help pitch in here.

[LeoniePhiline]

@maxcountryman Would you (as publisher of axum-sessions) mind publishing and maintaining a fork with an async-std / tokio feature flag?
Along what redis does: https://github.com/redis-rs/redis-rs/blob/main/redis/Cargo.toml#L78-L81

(Else I'll do that.)

[maxcountryman]

It feels like the more ideal thing here would be to incorporate that into this crate and avoid forking. Some axum-sessions users have built their own workarounds so that may be sufficient until the status of this crate can be resolved.

[LeoniePhiline]

Alright. Shall we try to reach @jbr by email or would that be obnoxious?
My impression is that he hasn't responded here since 2021. I assume he is unaware of the current goings-on in this issue tracker.

[LeoniePhiline]

Ah, he is. ❤️ Thanks for the feedback!

[0xAlcibiades]

@maxcountryman Would you (as publisher of axum-sessions) mind publishing and maintaining a fork with an async-std / tokio feature flag? Along what redis does: https://github.com/redis-rs/redis-rs/blob/main/redis/Cargo.toml#L78-L81

(Else I'll do that.)

Is there a reason to support async-std given that axum uses tokio?

[maxcountryman]

@LeoniePhiline if you're up for it, I think a fork will be necessary. I'm more than happy to point to your fork from the axum-sessions crate.

[LeoniePhiline]

@0xAlcibiades Using a feature flag for support of each runtime would mean hope to have this merged back upstream eventually.

While we discussing here are all axum users, the async redis session crate is agnostic.
Well, it obviously actually isn't (hard-coding async-std), but it claims and wants to be.

[LeoniePhiline]

@jbr Would you mind making a statement at this point? :) We would really very much appreciate it.

[jbr]

Hi folks! I'm catching up on this thread. I'd accept a PR that supports feature flags for both async-std and tokio. Is there a PR open like that I'm not seeing?

[jbr]

If there are larger differences than runtimes between implementations I don't have any concerns about there being multiple async-session adapters for redis. This crate (and async-session) was originally written for tide, and although I made an effort for async-session to be usable across runtimes and frameworks, I anticipated there to be a proliferation of different session stores for different platforms and datastores. I wrote a few stores initially to prove out the interface, of which this was one.

[0xAlcibiades]

There are a few, but this rolls all but 1 up into 1: #22 we can easily add a feature flag here. I also added using a multiplexed connection, which gets rid of the need for a tcp handshake each time, saving 25 ms best case and much more worst case.

[seg6]

Hey there! I intended to use the async-redis-session crate in a project of mine, but I decided to switch to the fred.rs Redis client as an alternative to the default adapter. I had thought about creating a PR to add it as a second adapter, but since the repo isn't very active, I decided to make it into its own crate (async-fred-session) for the time being. It could be a cool idea to implement it as an alternative adapter behind a feature flag in the future.