为什么Apache没有可行的mod_ruby呢？

像Ruby和Rails一样受欢迎,似乎这个问题已经解决了.JRuby和mod_rails都很精致,但是为什么不存在直接Ruby的Apache mod？

Phusion Passenger是一个强大的Apache模块,可以以最少的配置运行Rack应用程序.它对共享主机越来越有吸引力,将任何程序转换为Rack应用程序都非常容易:

Rack应用程序是 响应的Ruby 对象(不是类)call.它只需要一个参数,即环境,并返回一个恰好包含三个值的数组:状态,标题和正文.

基本问题是:长期以来,MRI是唯一可行的Ruby实现.MRI有许多问题使得很难将其嵌入到另一个应用程序中(这基本上就是mod_ruby所做的:它在Apache中嵌入了MRI),特别是多线程的(Apache是​​).它不是特别是线程安全的,它具有相当多的全局状态.

这一全球性的状态意味着,例如,如果一个Rails应用程序修改某些类,那么所有其他的同一个Apache服务器上运行Rails应用程序,将也看到这个修改的类.

另一个问题是MRI源代码不容易被破解.MRI已经超过15年了,它开始显示出来了.

由于这些问题,mod_ruby从未真正正常工作,并且在某些时候维护者只是放弃了.

另一方面,基于C的PHP解释器从第一天开始设计,在Apache中作为mod_php运行.实际上,对于前几个版本,甚至没有解释器的命令行版本,mod_php是运行PHP 的唯一方法.

Phusion Passenger(又名mod_rack又名mod_rails)通过基本放弃和回避问题解决了这个问题:他们只是在每个应用程序的单独过程中运行单独的MRI副本.它非常好用,不仅适用于Ruby.它支持WSGI(Python Web框架的标准接口),Rack(Ruby Web Frameworks的标准接口)和Ruby on Rails的直接支持.

我的希望是关于mod_rubinius,遗憾的是它还不存在.Rubinius从一开始就被设计为线程安全,可嵌入,没有全局状态,不使用C堆栈等.它被设计为能够在一个Rubinius进程中运行多个Rubinius VM.这使得mod_rubinius比mod_ruby更容易实现和维护.不幸的是,当然,Rubinius还没有被释放,而且在Rubinius被释放之前,关于mod_rubinius的真正工作甚至无法开始.好消息是mod_rubinius已经拥有了比mod_ruby更多的人力资源,因为它已经支付了由Rails托管公司开发的开发人员,他们迫切希望自己使用它.

也许值得双重澄清mislav的观点,即mod_rails实际上并不局限于Rails代码.新名称mod_rack更好.简单的小应用程序可以安装 - 他们的例子是:

class HelloWorld
  def call(env)
    [200, {"Content-Type" => "text/plain"}, ["Hello world!"]]
  end
end