mod_blosxom 2.0開発状況

By Hiroyuki OYAMA Thu Oct 2 21:59:18 2003

mod_blosxom2の開発は、休日の気分がのっているときしか取りかかっていないので、全然進んでいません。開発初期の段階でChangeLogを細かく書くのも個人的にアレなので、ここに書いてみるテスト。

変更点

Pluginのロードタイミング変更

先のpre1で宣言(?)したとおり、Apacheの起動時にインストール済みプラグイン(のDSO)をロードしておき、ユーザが独自に新しいプラグインをインストールしたりロードしたりできないような実装にしました。そのかわり管理者がインストールしたプラグインの中から、ユーザは利用するプラグインを選択してその実行順序を任意に指定できます。

BlosxomPluginDir /path/to/mod_blosxom/plugin/
 
<Location /blosxom>
    SetHandler blosxom
    BlosxomAddPlugin  revsort wikish ping
</Location>

BlosxomAddPluginディレクティブはLocationコンテナだけでなく、Directoryコンテナや.htaccessで記述する事ができます。この構成をとる事で

Abuseなpluginのインストールを防ぐ事ができる
予めPluginをロードするので、消費メモリの予測がたてやすい(嘘くさっ)
Apacheの起動時にPluginをロードし、リンクさせるのでパフォーマンス面で有利

といった感じのメリットが生まれます。そのかわり

あまり使用されないPluginによって、メモリが浪費される。
Pluginをインストール、変更した際にはApacheの再起動が必要。

ってなデメリットも生まれます。もっと賢くpluginを遅延ロード/アンロードするような仕組みにするのも楽しいかもしれません。

Plugin用APIをちょっと追加

プラグインに引き渡されるコンテキストから実行できる「プラグイン用API」をちょっとだけ追加／変更しました。

int is_entry(blosxom_context_rec *ctx, void *entry);

引数entryがmod_blosxomで読み込むべき記事か否かを判定するAPIで、次のように使用します。

char full_path[] = "/path/to/blosxom/entry.txt";

if (ctx->is_entry(ctx, (void *)full_path))
    fprintf(stderr, "is entry: \n", full_path);
else
    fprintf(stderr, "is not entry: \n", full_path);

デフォルトの実装では*.txtなファイルへのパスの文字列か否かで判定します。コンテキスト経由のAPIは差し換え可能なので、ファイル以外のストレージを使用するプラグインでctx->is_entryに独自の判定処理の関数ポインタを登録して使用します。あまり使わないかも。。。

void *includes_plugin(const char *name);

引数nameで指定した名前のプラグインがインストールされているか調べます。インストールされている場合は、指定されたプラグインのblosxom_plugin構造体のポインタを返します。特定のプラグインの機能を呼び出したい場合には

blosxom_plugin *plugin;
 
plugin = ctx->includes_plugin("wikish_blosxom_plugin.c");
content = plugin->interpolate(ctx, template);

といった感じに利用できます。

デフォルトは富豪

設計上の決めごととして、

デフォルトの動作は富豪に

としました。デフォルトでは記事ファイルへのパスと更新時刻を保持した配列を生成し、その全てをソートした後、配列の要素をたどりながら記事をレンダリングします。この実装だと大量の記事を抱えた場合に、それに比例したリソースを要求することになりますが、追加のプラグインでキャッシュを行わせる事で軽量化が可能です。
以前のmod_blosxomでもキャッシングを実装しようと考えていましたが、キャッシュのライフサイクルや手法が利用状況や用途によって様々なので結局実装しないまま放置していました。様々なキャッシングの手法やルールを個別のプラグインとして実装、組み込みできれば、用途や状況に応じたキャッシングが行えるようになるのではないかと期待しています。←誰に