search

jbr / async-redis-session

35 stars 15 forks source link

Maintenance status? #18

Open maxcountryman opened 2 years ago

maxcountryman commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

0xAlcibiades commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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

jbr commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

There are a few, but this rolls all but 1 up into 1: https://github.com/jbr/async-redis-session/pull/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.

nullptropy commented 1 year ago

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.