¿Por qué todavía no existe un mod_ruby viable para Apache?

Question

Por muy populares que sean Ruby y Rails, parece que este problema ya estaría resuelto.JRuby y mod_rails están muy bien, pero ¿por qué no hay un mod de Apache solo para Ruby?

Answer 1

El problema básico es este:Durante mucho tiempo, la resonancia magnética fue la única implementación viable de Ruby.La resonancia magnética tiene una serie de problemas que dificultan su integración en otra aplicación (que es básicamente lo que mod_rubí hace:incorpora MRI en Apache), especialmente uno de subprocesos múltiples (que es Apache).No es particularmente seguro para subprocesos y tiene bastante estado global.

Este estado global significa, por ejemplo, que si una aplicación Rails modifica alguna clase, entonces todos los demás Las aplicaciones Rails que se ejecutan en el mismo servidor Apache, también ver esta clase modificada.

Otro problema es que el código fuente de la resonancia magnética no se puede piratear fácilmente.La resonancia magnética tiene ahora más de 15 años y está empezando a notarse.

Como resultado de estos problemas, mod_ruby nunca ha en realidad funcionó correctamente y, en algún momento, los mantenedores simplemente se dieron por vencidos.

El intérprete PHP basado en C, por otro lado, fue diseñado desde el primer día para ejecutarse como mod_php dentro de Apache.De hecho, durante las primeras versiones, ni siquiera había una versión de línea de comandos del intérprete, mod_php era la solo forma de ejecutar PHP.

Phusion Passenger (también conocido como mod_rack y mod_rails) resuelve este problema básicamente renunciando y eludiendo el problema:simplemente ejecutan una copia separada de la resonancia magnética en un proceso separado para cada aplicación.Funciona muy bien, y no sólo para Ruby.Es compatible WSGI (interfaz estándar para Python Web Frameworks), Estante (interfaz estándar para Ruby Web Frameworks) y soporte directo para Ruby on Rails.

Mis esperanzas están puestas mod_rubinius, que lamentablemente aún no existe. Rubinio fue diseñado desde el principio para ser seguro para subprocesos, integrable, libre de estado global, no usar la pila C, etc.Fue diseñado para poder ejecutar múltiples máquinas virtuales Rubinius dentro de un proceso Rubinius.Esto hace que mod_rubinius sea infinitamente más fácil de implementar y mantener que mod_ruby.Desafortunadamente, por supuesto, Rubinius aún no se ha lanzado, y el verdadero trabajo en mod_rubinius ni siquiera puede comenzar hasta que se lance Rubinius.La buena noticia es que mod_rubinius ya tiene más mano de obra detrás de la que mod_ruby alguna vez tuvo, porque ha pagado a los desarrolladores que trabajan en él a través de una empresa de hosting Rails que desesperadamente quiere usarlo ellos mismos.

Answer 2

Hay Pasajero Phusion, un módulo Apache robusto que puede ejecutar Estante Aplicaciones con configuración mínima.Se está volviendo atractivo para los hosts compartidos y convertir cualquier programa en una aplicación Rack es ridículamente fácil:

Una aplicación Rack es Ruby objeto(no una clase) que responde a call.se necesita exactamente un argumento, el entorno y devuelve una matriz de exactamente tres valores:El estado, los encabezados y el cuerpo.

Answer 3

Quizás valga la pena aclarar dos veces el punto de mislav de que mod_rails en realidad no se limita en absoluto al código Rails.El nuevo nombre, mod_rack, es mucho mejor.Las aplicaciones trivialmente pequeñas se pueden almacenar en rack; su ejemplo es:

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

Answer 4

Hay uno: mod_rubí, pero no se ha mantenido en aproximadamente 2 años.

Answer 5

Hay mod_rails y puede correr Estante aplicaciones, ¿qué más puedes necesitar?