3 ms·
Loading plugins into Redis, a-la Dynamic Redis approach or otherwise, has long been discussed in the Redis community. Presently, antirez prefers not to destabli
by itamarhaber 11y ago
Loading plugins into Redis, a-la Dynamic Redis approach or otherwise, has long been discussed in the Redis community. Presently, antirez prefers not to destablize Redis (and thus damage its solid stability reputation) by allowing external code be run in it.
So, despite the obvious perks that we'll enjoy by side-loading our own junk, antirez's "Quality or DEATH" approach on this matter leaves no open questions about the possible inclusion of this functionality. There is, however, another way to get code running in Redis... it is called a GitHub Pull Request :) If you've thunk up something really amazing/useful and coded it, drop by the redis-dev mailing list to discuss it, maybe do an RCP and submit your code. No one promises that your PR will be accepted, but even if it won't make its way into the core, anyone will be able to use it nonetheless.
Another point worth mentioning in this context is that in order to even contemplate such a mechanism, Redis' core will need heavy refactoring of the internal API. This is by all accounts a huge effort that, if taken by the developer, is likely to postpone a lot of other important work.
- rakoo 11y agoAs someone outside to redis development, I'd like to know: is Dynamic Redis that more performant than good ol' lua scripts that it's worth introducing potential incompatibilities between redis instances deployments ? I stumbled upon the old discussion about adding a scripting language to redis, and the number 1 requirement was that additional code should be "migratable" very easily from instance to instance. A related question: is there some kind of repo for "useful lua scripts that everybody could use but didn't make it in core redis (yet)" ?
- antirez 11y agoDepends a lot on the kind of task at hand. For many things Lua is very fast, but not for implementing something like geocoding. On the other hand Dynamic Redis does not offer a proper API to Redis (I would be against plugins even if it was better in this regard, btw), so the assumption is that modules manipulate Redis internals in order to do anything remotely advanced, and you can't change a Redis internal without breaking modules, a constraint that we currently don't have at all: if the exported API is the same, we can improve Redis internals anytime without backward compatibility issues. This was crucial in the history of Redis.