mod_rails aka mod_rack aka mod_ruby

[Michał Jaszczyk]

Okay, people, let's sum this thread up.

Creting mod_rails/mod_ruby/mod_rack is not a good idea. There are some
ideas why such a module might be useful, but for every such idea
there's an explanation why it actually won't work. I'll try to
summarize them here:

- Making mod_r* makes things work faster. True indeed, but the
'things' we're talking about in here are just passing HTTP request to
the Rails/Rack app. But everyone surely knows that it's the time spent
inside Ruby/Rails is the most critical part, not passing HTTP request
to it.

- mod_r* would ease configuration. Yeah, it's really ridiculous.
Configuration of such module would be pretty much bound to it's
implementation, for example one would have to choose number of child
processes, subinterpreters etc. Pretty troublesome.

- Making a HTTP server is hard, so let's make mod_r*. Tricky one.
Making fast, robust, reliable etc. HTTP server (like the one whose
name starts with N and ends with x) is difficult. So is creating good
mod_r* module. It's far more easier to create simple HTTP server like
Mongrel or run R* app via FastCGI.

So these are the main arguments why mod_r* might be good idea and
explanations why these arguments do not hold. But the main reason why
mod_r* is bad (i.e. the one reason that convinced me) is the
'separation of concerns'/'bad design' reason. Those two things really
should not go together.

Thanks for all the input and a very interesting discussion. You taught
me a lot, guys!

Cheers,

Mike