Por que ainda não existe um mod_ruby viável para o Apache?

Question

Por mais populares que sejam Ruby e Rails, parece que esse problema já estaria resolvido.JRuby e mod_rails são ótimos e elegantes, mas por que não existe um mod Apache apenas para Ruby puro?

Answer 1

O problema básico é este:por muito tempo, MRI foi a única implementação Ruby viável.A ressonância magnética tem vários problemas que dificultam sua incorporação em outro aplicativo (que é basicamente o que mod_ruby faz:ele incorpora ressonância magnética no Apache), especialmente um multithread (que é o Apache).Não é particularmente seguro para threads e possui bastante estado global.

Este estado global significa, por exemplo, que se uma aplicação Rails modificar alguma classe, então todos os outros Aplicações Rails que rodam no mesmo servidor Apache, também veja esta classe modificada.

Outro problema é que o código-fonte da ressonância magnética não é facilmente hackeável.A ressonância magnética já tem mais de 15 anos e está começando a aparecer.

Como resultado desses problemas, mod_ruby nunca realmente funcionou corretamente e em algum momento os mantenedores simplesmente desistiram.

O interpretador PHP baseado em C, por outro lado, foi projetado desde o primeiro dia para ser executado como mod_php dentro do Apache.Na verdade, nas primeiras versões, não havia nem mesmo uma versão de linha de comando do interpretador, mod_php era o apenas maneira de executar o PHP.

Phusion Passenger (também conhecido como mod_rack ou mod_rails) resolve esse problema basicamente desistindo e evitando o problema:eles simplesmente executam uma cópia separada da ressonância magnética em um processo separado para cada aplicação.Funciona muito bem, e não apenas para Ruby.Ele suporta WSGI (interface padrão para Python Web Frameworks), Prateleira (interface padrão para Ruby Web Frameworks) e suporte direto para Ruby on Rails.

Minhas esperanças estão mod_rubinius, que infelizmente ainda não existe. Rubínio foi projetado desde o início para ser thread-safe, incorporável, livre de estado global, não usar a pilha C e assim por diante.Ele foi projetado para ser capaz de executar várias VMs Rubinius dentro de um processo Rubinius.Isso torna o mod_rubinius infinitamente mais fácil de implementar e manter do que o mod_ruby.Infelizmente, é claro, o Rubinius ainda não foi lançado, e o trabalho real no mod_rubinius não pode nem começar até que o Rubinius seja lançado.A boa notícia é que o mod_rubinius já tem mais mão de obra por trás dele do que o mod_ruby jamais teve, porque ele pagou desenvolvedores trabalhando nele por uma empresa de hospedagem Rails que desesperadamente quer usá-lo sozinho.

Answer 2

Há Passageiro Fusão, um módulo Apache robusto que pode executar Prateleira aplicativos com configuração mínima.Está se tornando atraente para hosts compartilhados, e transformar qualquer programa em um aplicativo Rack é ridiculamente fácil:

Uma aplicação Rack é um Ruby objeto(não uma classe) que responde a call.É preciso exatamente um argumento, o meio ambiente e retorna uma variedade de exatamente três valores:O status, os cabeçalhos e o corpo.

Answer 3

Talvez valha a pena esclarecer novamente o ponto de vista de Mislav de que mod_rails não está realmente limitado ao código Rails.O novo nome, mod_rack, é bem melhor.Aplicativos trivialmente pequenos podem ser rackable - seu exemplo é:

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

Answer 4

Há um: mod_ruby, mas não é mantido há cerca de 2 anos.

Answer 5

Há mod_rails e pode ser executado Prateleira aplicações, o que mais você pode precisar?