I see that this project mentions an "ORM" for Redis. I have two somewhat naive questions:
First of all, as far as I know, Redis is not relational, so ORM seems kind of dubious. Secondly: is Redis suited as the main, persistent storage for an application?
I had the impression that it is more of a memcached replacement with more complex data structures than an actual database.
There are ways to get the data in Redis onto disk, but AFAIK those are mainly for data recovery, and you take a performance hit when you use them. Being used as a primary store is outside of the normal use case for Redis, IMHO (though I love using it for exactly what you think it is)
You can tune Redis to fit many use cases, but in a situation where you have choice it feels like a bad idea to take it out of it's comfort zone just because.
One thing that I don't understand is why Mongrel2 didn't really took off in the webserver world. It seems a complete product and the concept behind it is very nice.
Plus, it doesn't need any external module to work with a specific language, given that ZeroMQ is used to communicate with the backend.
It surprised me as well. Maybe because of Zed. I like him though.
I also have a distant memory of Mongrel2 being licensed under AGPL. In fact I just googled it and yes, it was licensed under AGPL but it now seems to be BSD-licensed.
I feel like Zed gave up on this project too early. He created it, gave it an initial promotional push and then "turned it over to the community."
There were a faithful few people who kept contributing to the project, but it did not have anyone pushing the project forward significantly after Zed left.
I liked him, and then one day he was being a complete asshole about something (as I recall he was making shitty comments about people who buy Apple products), I tweeted him saying 'using inflammatory and hostile language doesn't help you get your point across', and he said 'THANKS DAD' and blocked me.
So, I dunno. He's a smart programmer and a smart person, but flipping your shit on Twitter doesn't really make a whole lot of sense.
I like him too, he's brash, works on interesting stuff, and most importantly, put it out there. His public persona engenders a strong response from some and has opened him up to a lot of criticism, which he's proven (countless times) he doesn't handle well. But then who does really?
My hypothesis is because of zeromq, I basically have to code a zeromq client as the backend. This is not convenient; I don't get to use any of the existing frameworks in my ecosystem. Plus since zeromq messages are defined by length, I've always wondered how one would stream data in the response, ie one would have to know the response size before sending back thru to mongrel2.
If anyone has experience with using mongrel2, I'd love to hear, I have not been interested enough to go research it myself however.
Well, there are already libraries which abstracts the ZeroMQ layer with Request/Response interfaces.
A few months ago I hacked a bit with a Zend Framework 1 application and Mongrel2 and it worked well, although zf1 is not the best example given the fact that it was designed to work in a classic mod_php environment where the PHP process doesn't keep its state between requests.
At first blush, it didn't seem implausible to write a ZeroMQ SAPI, like PHP-FPM, or to modify an existing SAPI (e.g. FPM) to consume ZeroMQ sockets. I was actually really excited to see where people would take that.
What I realized later was that it didn't happen because a lot of PHP is deployed to shared/managed hosts, and people willing/able to deploy code like Mongrel2 are unlikely to be using PHP. The venn diagram of 'people capable of building out a PHP SAPI' and 'people interested in bleeding-edge experimentation like Mongrel2' doesn't overlap enough to produce results.
Here is my personal theory. The configuration was too hard.
Configuration had to be compiled from a python-esque format into a database. When you wanted to change a config setting, you needed to modify the source file and then compile the config back into a database (sqlite, as I recall).
I really wanted to like Mongrel2. But every time I went tried to change a configuration setting in development, I became frustrated.
I think this is an example of trying to do too many new things at once. Just pick one thing (be an app server) and do it well.
Even if compiling your config into a DB is a good idea, it won't matter if it makes it so hard to use your product that few people will.
24 comments
[ 4.7 ms ] story [ 45.2 ms ] threadFirst of all, as far as I know, Redis is not relational, so ORM seems kind of dubious. Secondly: is Redis suited as the main, persistent storage for an application?
I had the impression that it is more of a memcached replacement with more complex data structures than an actual database.
Maybe it stands for "Object-Redis mapping"
Plus, it doesn't need any external module to work with a specific language, given that ZeroMQ is used to communicate with the backend.
I also have a distant memory of Mongrel2 being licensed under AGPL. In fact I just googled it and yes, it was licensed under AGPL but it now seems to be BSD-licensed.
There were a faithful few people who kept contributing to the project, but it did not have anyone pushing the project forward significantly after Zed left.
So, I dunno. He's a smart programmer and a smart person, but flipping your shit on Twitter doesn't really make a whole lot of sense.
The vast majority of people handle constructive criticism better than 'throw a tantrum on Twitter and block everyone who replies to you'.
If anyone has experience with using mongrel2, I'd love to hear, I have not been interested enough to go research it myself however.
They have a 'mp3stream' example at https://github.com/zedshaw/mongrel2/blob/master/examples/mp3...
A few months ago I hacked a bit with a Zend Framework 1 application and Mongrel2 and it worked well, although zf1 is not the best example given the fact that it was designed to work in a classic mod_php environment where the PHP process doesn't keep its state between requests.
What I realized later was that it didn't happen because a lot of PHP is deployed to shared/managed hosts, and people willing/able to deploy code like Mongrel2 are unlikely to be using PHP. The venn diagram of 'people capable of building out a PHP SAPI' and 'people interested in bleeding-edge experimentation like Mongrel2' doesn't overlap enough to produce results.
Configuration had to be compiled from a python-esque format into a database. When you wanted to change a config setting, you needed to modify the source file and then compile the config back into a database (sqlite, as I recall).
I really wanted to like Mongrel2. But every time I went tried to change a configuration setting in development, I became frustrated.
I think this is an example of trying to do too many new things at once. Just pick one thing (be an app server) and do it well.
Even if compiling your config into a DB is a good idea, it won't matter if it makes it so hard to use your product that few people will.
1. Being able to automatically adjust your configuration/db on the fly
2. Using ZeroMQ for everything so that you can tell your backends about your frontend and not vice-versa.
Turns out neither one of those is really worth changing away from a static configuration like nginx or apache.
I loved the idea of Photon. Never actually tried it, but it is a really nice idea.