というわけでここ数日 Plagger Blog みたいになってますがご容赦を。Plagger ネタを追いかけたい方は del.icio.us の plagger タグ でほぼ網羅できているとおもうので、ここをチェック。
で、Plagger とプラグインシステムです。「なんで Plagger はプラグインをコアの中にいれて配布しているの？ 別個に配布したほうが便利なのに」 という疑問を当然お持ちの方もいるかとおもいました。
ここはだいぶ議論になったところで（といっても IRC チャネル #plagger-ja で小１時間しゃべっただけですが）、実際に Trac でチケット #44: Reorganize plugin directories in SVN も切られてます。
ただ、現状は svn の plagger/lib/Plagger/Plugin 以下に svn commit してもらう方法をとっていて、これが最適だとおもっています。その理由を説明する前に、Perl でつくられたソフトウェアがどのようにプラグインをロードしているかの例を調べたので、ちょっと紹介しましょう。
Ingy dot Net による "DIY Wiki building kit" ともいうべき Wiki システム。ほとんどすべてがプラグインで構成されています。
* プラグインの作成方法: Perl モジュール
* プラグインの配布方法: CPAN / Ingy の svn レポジトリ
* プラグインのロード: Kwiki::Installer に対応したプラグインの場合は、kwiki -add Kwiki::Foo を実行。それ以外の場合、各 Kwiki インストレーションの plugins ファイルにモジュール名を書き込む。設定は config.yaml に共通
長所: CPAN で配布が可能
短所: Kwiki コアの API が変わると、古いプラグインが動かなくなる
Kwiki の開発はかなり安定してきているので、CPAN を利用した配布方法も現実的です。ただ、ちょっと前までは、Ingy が Kwiki のバージョンをあげると、動かなくなるプラグイン続出、という状況でした。"Ingy, you broke my Kwiki plugin" というセリフを何度聞いたことか。
Ask Bjorn Hansen による SMTP サーバ構築キット。これも、すべてがプラグイン。
* プラグインの作成方法: ファイルを plugins/ 以下におく
* プラグインの配布方法: svn で qpsmtpd のコアにインクルード
* プラグインのロード方法: config/plugins にプラグインファイル名を１行１モジュールで記述。設定はスペース区切りの引数で追加
長所: svn で管理しているため、本体との API の整合性がとりやすい
短所: CPAN からインストールできない
qpsmtpd は CPAN にはリリースされておらず、svn での開発がメインとなっています。debian のパッケージや ports などが用意されているので、CPAN からインストールできないデメリットはあまり感じません。
* プラグインの作成方法: ファイルに記述。モジュール化したりテンプレートといっしょにディレクトリにバンドルしたりすることが可能
* プラグインの配布方法: Plugin Direcotry または各自のサイト
* プラグインのロード: plugins/ ディレクトリにファイルまたはディレクトリごと配置。ロード後、MT 管理画面から enable/disable することも可能
* プラグインの設定: 各プラグインの管理画面から設定
長所: ただファイルを配置するだけから、 高度なプラグイン開発、設定まで幅広く対応可能
短所: Plugin Directory などのサイトを検索する必要。また開発者にとってはディレクトリサイトの管理などの手間
MT はそれ自体完成したソフトであり、またオープンソースのライセンスではないので、CPAN からという手段は考える必要がありませんね。
というわけで Plagger です。現状はこうです。
プラグインの作成方法: Perl モジュール
プラグインの配布方法: svn の plagger ディストロ内
プラグインのロード: config.yaml に module: ブロックを記述
というわけで現状は、作成とロードを Kwiki に学び、配布を qpsmtpd に学んでいます。ただし Perl モジュールの形式なので、あとあと CPAN にアップすることも可能になっていますし、プラグインのロードはファイル単位でおこなうこともできます（#8 参照。config.yaml で指定した plugin_path: にファイルをおけば、lib/Plagger/Plugin/Foo/Bar.pm なんてところに野良プラグインをおかなくても大丈夫です）。
リリースごとに API を変更している現状や、コミッターがどんどん増えている状況を考えれば、現状これが最適にワークしていると思えます。もしそうでなければ、ユーザは、必要になるプラグインを全部別個にインストールしなくてはならず、プラグインのデベロッパーは、Plagger コアやその他のプラグインの依存関係をケアしながら Makefile.PL を記述して１個ずつ CPAN に毎回アップして、その CPAN のミラーに半日かかるのを待って ... なんてバカげたことをしなくてはなりません。時間とリソースの無駄。
Plugin を同梱することでインストールがめんどうになっているのでは？ という疑問についてはこれは誤解です。外部プラグインが必要とするモジュールについては 0.5.4 から Makefile.PL にすべて記述していますし、オプショナルと思えるプラグインについては、デフォルトで [n] となってスキップします。
UNIX システム (Linux や Mac OSX) でもっとも簡単な方法は、CPAN シェルで cpan> test Plagger として依存モジュールをインストールし、あとは svn up で Plagger の最新を「インストールせずに」使うということでしょう。Win32 ではたしかにメンドウですが CPAN シェルと ppm で依存モジュールをいれてしまえば、あとは pure perl なので大変なところはないはずです。
もっとくわしくプラグインの実装方法について知りたい！ という方は、qpsmtpd の作者である Ask の Build Easily Extensible Perl Programs (PDF) が参考になるかも。