Perché non esiste ancora un mod_ruby praticabile per Apache?

Question

Per quanto popolari siano Ruby e Rails, sembra che questo problema sia già stato risolto.JRuby e mod_rails sono tutti ottimi ed eleganti, ma perché non esiste un mod Apache solo per Ruby?

Answer 1

Il problema di base è questo:per molto tempo, la risonanza magnetica è stata l'unica implementazione Ruby fattibile.La MRI presenta una serie di problemi che rendono difficile incorporarla in un'altra applicazione (che è fondamentalmente ciò che mod_ruby fa:incorpora la risonanza magnetica in Apache), in particolare multi-thread (che è Apache).Non è particolarmente thread-safe e ha un bel po' di stato globale.

Questo stato globale significa ad esempio che se un'applicazione Rails modifica qualche classe, allora tutti gli altri Le applicazioni Rails eseguite sullo stesso server Apache lo faranno Anche vedere questa classe modificata.

Un altro problema è che il codice sorgente della risonanza magnetica non è facilmente hackerabile.La risonanza magnetica ha ormai più di 15 anni e inizia a farsi vedere.

Come risultato di questi problemi, mod_ruby non ha mai Veramente funzionava correttamente e ad un certo punto i manutentori semplicemente si arrendevano.

L'interprete PHP basato su C, invece, è stato progettato fin dal primo giorno per essere eseguito come mod_php all'interno di Apache.Infatti, per le prime due versioni, non c'era nemmeno una versione a riga di comando dell'interprete, mod_php era il soltanto modo di eseguire PHP.

Phusion Passenger (noto anche come mod_rack o mod_rails) risolve questo problema sostanzialmente arrendendosi ed eludendo il problema:eseguono semplicemente una copia separata della risonanza magnetica in un processo separato per ogni applicazione.Funziona alla grande, e non solo per Ruby.Supporta WSGI (interfaccia standard per Python Web Framework), Cremagliera (interfaccia standard per Ruby Web Frameworks) e supporto diretto per Ruby on Rails.

Le mie speranze sono accese mod_rubinius, che purtroppo ancora non esiste. Rubinio è stato progettato fin dall'inizio per essere thread-safe, incorporabile, privo di stato globale, non utilizza lo stack C e così via.È stato progettato per poter eseguire più VM Rubinius all'interno di un processo Rubinius.Ciò rende mod_rubinius infinitamente più semplice da implementare e mantenere rispetto a mod_ruby.Sfortunatamente, ovviamente, Rubinius non è ancora stato rilasciato, e il vero lavoro su mod_rubinius non potrà nemmeno iniziare finché Rubinius non sarà rilasciato.La buona notizia è che mod_rubinius ha già più personale alle spalle di quanto mod_ruby abbia mai avuto, perché ha pagato gli sviluppatori che ci lavorano tramite una società di hosting Rails che disperatamente vuole usarlo da solo.

Answer 2

C'è Passeggero di fusione, un robusto modulo Apache che può essere eseguito Cremagliera applicazioni con configurazione minima.Sta diventando attraente per gli host condivisi e trasformare qualsiasi programma in un'applicazione Rack è ridicolmente semplice:

Un'applicazione Rack è un Ruby oggetto(non una classe) a cui risponde call.Ci vuole esattamente un argomento, l'ambiente e restituisce esattamente una serie tre valori:Lo stato, le intestazioni e il corpo.

Answer 3

Forse vale la pena chiarire il punto di Mislav secondo cui mod_rails in realtà non è affatto limitato al codice Rails.Il nuovo nome, mod_rack, è decisamente migliore.Le app banalmente piccole possono essere installabili su rack: il loro esempio è:

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

Answer 4

C'è uno: mod_ruby, ma non è stato mantenuto da circa 2 anni.

Answer 5

C'è mod_rails e può funzionare Cremagliera applicazioni, cos'altro puoi volere?