MojoとHTTP::Engine

ここまでMojoとそのサンプルフレームワークであるMojoliciousについて見てきましたが，国内でもYappoこと大沢和宏さんとtokuhiromこと松野徳大さんが中心となって，HTTP::Engineという同じような趣旨のフレームワークが開発されていることをご存知の方も多いと思います。今回はそのHTTP::EngineとMojoを比較しながら，Mojoの歴史や展望を見ていきましょう。

HTTP::Engineの誕生

HTTP::Engineも，もとをただせばMojoの作者ゼバスティアン・リーデル（Sebastian Riedel）氏が4年ほど前にリリースしたCatalystというフレームワークから派生したものです。だから，Mojoとは義理のおじ，あるいは いとこ・はとこ くらいの関係になるでしょうか。

CatalystもCPANモジュールをつなぐ「触媒」と言われていたくらいで，もとよりWSGI的なミドルウェアになる素質は持っていました。ところが，原作者リーデル氏や，その後メンテナンスを引き継いだ開発チームがコミュニティを根底から揺るがすような方針変更を繰り返したため，Catalystの周辺モジュールに対する期待感や信頼感はがた落ちしていきます。あれもだめ，これもだめという具合にブラックリストに載る周辺モジュールの数が増えていった結果，結局コアのエンジン部分だけあればよいのではないかという話になったのがHTTP::Engine誕生のきっかけでした。

アプリケーションの書き方に大差はありません

そのインタフェースについては紆余曲折がありましたが，いまではCatalyst（や，Mojo）とは多少異なったものになっています。比較のために連載第1回でとりあげたHelloWorldアプリケーションをHTTP::Engineで書き直してみましょう。lib/HelloWorld.pmからコンテキスト（トランザクション）オブジェクトが消えているのがわかるでしょうか（ここではあえて冗長に書いていますが，実際にはもう少しコンパクトに書くこともできます⁠）⁠。

package HelloWorld;

use strict;
use warnings;
use HTTP::Engine::Response;

sub handler {
    my $req = shift;
    my $res = HTTP::Engine::Response->new;
    $res->status(200);
    $res->headers->content_type('text/plain');
    $res->body('Hello HTTP::Engine!');
    return $res;
}

1;

スタンドアロンサーバを起動するためのスクリプトはこんな感じです。

#!perl
use strict;
use warnings;
use lib 'lib';
use HTTP::Engine;
use HelloWorld;

HTTP::Engine->new(interface => {
    module => 'ServerSimple',
    args => {
        port => 3000,
    },
    request_handler => 'HelloWorld::handler',
})->run;

このくらいのアプリケーションであればlib/HelloWorld.pmの中身をスクリプト内部に書いてしまうこともできるのですが，それはさておき，HTTP::Engineのアプリケーションの書き方も，基本的にはMojoの場合と大差ありません。開発コミュニティが日本人に偏っていたとはいえ，Catalystの開発チームからはおおむね好意的に迎えられた結果，HTTP:EngineのIRCチャンネルには海外の開発者の姿も見られるようになっていました。リーデル氏にはHTTP::Engineの改善を進めるという道もあったはずです。

それなのに，なぜリーデル氏はあえてMojoを生み出したのでしょうか。

DRYとDIY

MojoとHTTP::Engineのもっとも顕著な違いは，CPANモジュールに対する態度といえます。

HTTP::Engineや，そのもととなったCatalystは，Perl界の定石にのっとって，定番のCPANモジュールがあればなるべくそちらを利用するような形で開発が行われてきました。

ただし，定番のモジュールといっても，かならずしもインターネットの標準に準拠しているとは限りません。速度や手間とのトレードオフを考えて手抜きが行われていたり，そもそも標準が制定される前の実装であったりと，理由はさまざまですが，どこかしら不完全な部分を抱えているものです。

たとえば，HTTP::EngineやCatalystが利用しているHTTP::BodyやCGI::Simpleには，いまなおRFCに準拠していない箇所があるというバグレポートが届いていますし（※1⁠）⁠，スタンドアロンサーバに利用しているHTTP::Server::SimpleもHTTP/1.1の機能をフルに実装しているわけではありません。

※1

http://rt.cpan.org/Public/Bug/Display.html?id=34310
http://rt.cpan.org/Public/Bug/Display.html?id=41407

そんなHTTP::EngineやCatalystを反面教師に生まれたMojoは，一部のコアモジュールを除いて外部のモジュールは利用していません。フォームデータのパースも，URLの操作も，リクエストやレスポンスの取り扱いも，すべて自前で行っています。

リーデル氏のねらいは，ともすれば標準が定まる前からあるような古いモジュール，実装の不十分なモジュールを一掃することで，つもりつもったバッドノウハウや古びたインタフェースに引きずられることなく，より現代的な，標準に準拠した，統一感のある実装を行うことにありました（これまで詳しく取り上げませんでしたが，paramメソッドひとつとってもCGI.pmなどのparamメソッドとは細かな挙動が異なっています⁠）⁠。

リーデル氏は現在CPANにあがっているモジュールのなかでMojoだけがクッキーを正しく処理できると主張していますが，その是非はさておき，インターネットの標準に対する意識が高いことはリポジトリにRFCのテキストが含まれていることからもうかがえます。