Hacker News new | past | comments | ask | show | jobs | submit login

I love Redis, but I'm a bit skeptical of some of the changes that are currently in development. The respv3 protocol has some features that, while they sound neat, also could significantly complicate client library code. There's also a lot of work going into a granular acl. I can't imagine why this would be necessary, or a higher priority than other changes like multi-thread support, better persistence model, data-types, etc.



Thanks coleifer, I understand that the current development path may look odd, but it's definitely not the first time: the critiques for Lua scripting or Pub/Sub where much stronger AFAIK :-) However I want to really share what is the process behind and why certain features like ACLs are so important (for reasons very different than the ones you may guess I think, that is, no enterprise customers in need for security), and why RESP3 has out-of-band data channels support (even if they are not implemented by the server). I'll write a blog post today, and reply here with the address. Cheers!

P.S. I'll also address threading and persistence.


Thank you for taking the time to respond so thoughtfully to my comment. If I had been talking directly to you, I hope I would have written something less entitled and expressed more gratitude for the gifts you've given the community, and which you continue to improve.

Redis is exactly the kind of software that gives me joy. Aesthetically and intellectually. Its pieces are orthogonal -- a word you used in your blog post. The code is small, tight, and well designed. It invites you to think more creatively. The lolwut command was also a very good innovation!


Your comment was already great. It was the comment of somebody that cares about Redis and is closely observing what direction it is headed. Also I went through your own set of questions exactly and decided to do certain things after some consideration: it's not obvious at all if this was the right decision but at least the process can be made transparent. Thanks!


The good thing is that you have a direct line of communication with the developer himself, @antirez on this portal or GitHub. From what I know, @antirez calls the shots on what gets implemented in Redis core...NOT Redis Labs. After reading several technical/non-technical posts at http://antirez.com, I can confidently say that his decisions are always sound and justifiable! We love you @antirez!


So nice words, thanks! I'll go ahead after this encouragement to try to reply to the OP about why I'm doing certain things.


Ok finally I wrote the post, sorry for the delay: http://antirez.com/news/126 and thanks for the feedbacks.


Nice & succinct problem definition for why ACLs are so important for everyone:

> Let me show you an example. You have a Redis instance and you plan to use the instance to do a new thing: delayed jobs processing. You get a library from the internet, and it looks to work well. Now why on the earth such library, that you don’t know line by line, should be able to call “FLUSHALL” and flush away your database instantly? Maybe the library test will have such command inside and you realize it when it’s too late. Or maybe you just hired a junior developer that is keeping calling “KEYS *” on the Redis instance, while your company Redis policy is “No KEYS command”.

Without ACLs we need to rely on command renaming or completely isolating databases to guard against errors. ACLs sound complicated but they're actually a solid user experience improvement.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: