Thanks for the question. I think having a configurable runtime makes sense. It seems in-line with ensuring flexibility (despite the dominance of tokio).

from async-redis-session.

The question was based on a misunderstanding of how the crate features interact. However, the motivation remains and thus an iteration on the question.

I needed to use redis with the following features:

[dependencies.redis]
version = "0.21.5"
features = ["aio", "async-std-comp", "async-std-tls-comp", "tls", "tokio-comp", "tokio-native-tls-comp"]

It would not compile with async-redis-session. My versions of the overlapping types did not match. The messages were a bit cryptic and led me to ask the first question.

In the end, I got the code to compile by changing async-redis-session dependencies to align with what I was using in redis. This means I have my own version of the package (path = ../async-redis-session).

[dependencies.redis]
version = "0.21.5"     # << align with redis
features = ["aio", "async-std-comp"]

I did try to simply downgrade the version of redis to accomplish the alignment task. I may have missed something, but I could not get it to work that way.

I would submit a PR with the updated dependency, but suspect that that might cause issues for others. I'm not sufficiently versed in managing these dependency issues.

Reworded question

What is the best way to align the version of redis with that of async-redis-session? The snag is how to do so while enabling ssl (i.e., the feature set as described).

PS: The session works really well with redis. It's truly amazing how simple it was to add this state functionality to the service. Thank you!!

from async-redis-session.

I maintain an axum middleware that provides cookie-based sessions via async-session. There's an ongoing issue thread regarding this crate. I'm curious if there's interest in following suit with async-sqlx-session and making it such that the async runtime is configurable?

from async-redis-session.

@jbr any thoughts?

from async-redis-session.

Thanks for the question. I think having a configurable runtime makes sense. It seems in-line with ensuring flexibility (despite the dominance of tokio).

I opened #23 which adds tokio support and multiplexing. I think the issue here seems to be no movement from the maintainer @jbr since June 2021. @maxcountryman is there any interest in you maintaining an authoritative fork of this?

from async-redis-session.

@0xAlcibiades given the lack of response, yes I think a fork is the way forward. I may not be the best person to maintain it but I'd be happy to help and would be glad to link to it directly from the axum-sessions crate.

from async-redis-session.