私達は、ここEYでmod_rubiniusへの取り組みを始めたばかりです。今回、Eero Saynatkari氏 (Rubinius IRC チャンネルの重要人物) とフルタイムの契約をして、プロジェクトに参加してもらうことになりました。Ezra氏は、Rack(サイト・英語)について、Rack自体もそのように言っているが、次のように説明している。
mod_rubiniusのアーキテクチャは、現時点ではまだ固まっていません。わかっていることは、Rackベースになることと、そのために、mod_rubinisからRubyアプリケーションへのインターフェイスがRackを経由することです。この点以外のことについて、プラットフォームをどのように組み立てるのが最適であるかはまだはっきりしていません。apacheプロセス内の組み込みのrubinius VMとなる可能性もあります。また、別個の複数のrubinius VMを管理するプロセスマネージャかもしれません。あるいは、この両方の方法の混合となる可能性もあります。
Rackは、RubyおよびRubyフレームワークをサポートするWebサーバ間の最小限のインターフェイスを提供します。Eeroは、Rubiniusとmod_rubiniusの作業の計画について次のように語っている(source)。
mod_rubiniusの作業自体は、当然、Rubiniusの作業を必然的に多く含むことになります。特に最初は、少なくとも、マルチVM (Rubiniusは、ネイティブスレッドごとに完全に別個のインタープリタを実行できる)、Rubinius独自のCインターフェイス (Subtendとは異なる)、および基本的なI/O層の領域ではそうなります。.Rubiniusの詳細については、InfoQのRubiniusについての記事(source)を参照。
あなたにも、mod_rubiniusの作業に対する発言権があります! Ezraのサイト(source)を訪れ、Merb、Ramaze、Rails、Nitro、IOWA、単純なCGI、または夢のようなアプリケーションの配置についてご意見をお聞かせください。
原文はこちらです:http://www.infoq.com/news/2008/02/engineyard_modrubinius