redimension

redimension copied to clipboard

I raised some concerns on Twitter about relying on the redic client, for a trivial popularity argument, not anything else basically. @soveran proposed several solutions here: https://github.com/antirez/redimension/commit/37554bb7f564b44091b53bc735cb9e70706bee0d#commitcomment-14092099

I'm opening this issue to discuss, and to propose yet another solution among the options we have.

My idea is that we should abstract this away from a specific client, and just provide an object that is able to reply to some API that can be implemented as a wrapper on top of any other Redis Client.

However my feeling is that, for the popularity concerns I've, it's better if we model this API to be similar to redis-rb so that it works trivially in that case. So basically in my proposal the Redis object passed to Redis must be able to reply to the four commands used (should be four AFAIK), plus #pipelined, plus #eval. This way we may pass directly a redis-rb object, or may wrap a redic object into an object which proxies such an API. We can also provide directly the wrapper for different clients (basically redic since AFAIK there are no other popular enough clients).

Another solution would be to instead expect the Redis object we pass to Redis to respond to more redic alike APIs, and implement proxies for both libs for redis-rb (since anyway, there is no natural way to handle pipelining or alike). Maybe this approach could be more sounding... because should be simpler to provide a proxy for redis-rb that already has internally a connection object that replies to raw commands.

The problem with all that is if also the replies reported by different client libs are different. Than the proxy must perform the transformation too, which may be slow.

Ideas?

Well, to keep it simple wrapping a redis-rb like type is pretty easy after all: https://gist.github.com/badboy/a8e86cca9c23c60bb621

Yes @badboy, it's probably more complex to wrap a redic object in order to export a redis-rb alike API.

I really like the idea of adding those methods to redis-rb no matter what we decide on this issue. By having that API, redis-rb could be used with any new Redis command (or any renamed commands) without having to wait for a new release and without resorting to method_missing.

I like that as well.

Huge +1 to that as well.

Oh, wait, I have push rights there, I can just add it. :D /cc @djanowski

Last word should be of Damian indeed given he does most of the developments.