Request for supporting the Redis scheme

[joshnatis]

Hi there, hope you're doing well.

Redis is an in-memory data store, similar in some ways to Memcached (in case you haven't heard of it....). It's been around for a while, and it has its own schema as described at https://www.iana.org/assignments/uri-schemes/prov/redis.

Many languages have clients for connecting to Redis clusters, but some of them do not know how to process URLs in the redis://<user>:<password>@<host>:<port> format, in which case it would be really helpful to use URI module to break the URL into parts and pass them as respective arguments. The perl-redis Redis client is one of these clients.

I would write my own lib/URI/Redis.pm and raise a PR, but my Perl-fu is sadly not strong enough.

Also, it seems that there is a module on CPAN that does just this: https://github.com/mendel/URI-redis, but it has very little traffic. If we could get the redis scheme to be native to URI that would be cool.

Thank you!!

[genio]

Hi @joshnatis. While I don't see this as a bad idea, let me try to explain why I don't think it can work.

For Redis use in Perl, we have mostly three options:

1. Redis
2. Redis::hiredis
3. Mojo::Redis

Neither of those modules accept a URI object for their constructors. Given that limitation on the downstream modules, even if we implement such a URI schema here, there wouldn't be any real way to make use of it. Basically, I see this as one of those, "yes, we can do it, but it wouldn't get used and would kind of just sit there".

In light of that, I'm going to go ahead and close this out for now. However, please keep looking for ways to help us improve things. We would appreciate any and all help you could provide. I'll also be happy to re-open this should anyone disagree with my assessment here as I'm well known to get things wrong.

Thanks again! Chase

[joshnatis]

Hey Chase, thanks a lot for the quick reply, put a smile on my face to see your email :)

Thanks as well for a tour of the Perl Redis landscape.

I am convinced by your argument, though I was just planning to use the functionality to parse a given Redis cluster URL and then manually supply the parts to the client (as opposed to passing in the URI object itself).

Parsing a URL like this manually is pretty simple (especially since I can be reasonably convinced it’ll stay in the same format), but I figured my team at work would prefer something more official :P.

Thanks again for your time!

[oalders]

I was just planning to use the functionality to parse a given Redis cluster URL and then manually supply the parts to the client (as opposed to passing in the URI object itself).

I can see why this might be helpful. Any reason not to use https://metacpan.org/pod/URI::redis for this?

[joshnatis]

Hey Olaf,

Honestly I don't have a great reason :P, URI::redis does the job. I guess I was a bit apprehensive about adding a module with seemingly very low traffic as a dependency for our production service. I'm not sure how rational of a fear that is to have...

EDIT: Looking again, the last commit to the repository was 7 years ago, so another point is that I would have a lot more confidence depending on a module that is actively maintained (this issue demonstrates my point well :D, I got a reply from Chase on the very same day).

[oalders]

Looking again, the last commit to the repository was 7 years ago, so another point is that I would have a lot more confidence depending on a module that is actively maintained

That's a valid concern. At my $work there would be lots of pushback on adding a module which hasn't been touched in a lot of years.

The bigger issue with adding it directly to URI is that we're now stuck maintaining something that likely none of us use or feel passionately about and we're already a very small group of volunteers maintaining a lot of stuff. That's after trying to contact the author to get permission to absorb it into URI. That in itself can take a very long time, based on how easy the author is to find.