2004-09-24 (Fri) [長年日記]
_ libapreqのインクルード
Debianのlibapreqパッケージにもれなくperl bindingが付いてくるのが 嫌で、svn headにlibapreq本体を取りこんでみた。
元のlibapreqは、Apache2では動かない*1ので、 ちょっと手を加えてApache1/Apache2の両方で使えるようにした。 あと、元のと名前がぶつからないように、関数名にプリフィックスを 付けておいた。
*1 libapreq2なら対応してるけど、Apache2専用
_ Webアプリケーションフレームワーク
ちょっとWebアプリケーションフレームワークを作ってみようかな。
- クエリの解析やHTMLの生成などを行うフロントエンドは、mod_ruby上 (CGIでもいいけど重そう)で動かす。
- ロジックは、アプリケーション毎に独立したプロセスで動かす。
- コンポーネントのサポート。
- イベントドリブン。
- セッションには継続を使う。したがって、アプリケーションは同時に 1つのリクエストしか処理できない。クライアントとの入出力はmod_ruby 側でやるから、あまり問題はない(と思いたい)。
要は、Webアプリケーションが書くのが嫌いなので、なるべく 普通のGUIアプリケーションっぽくしたいのだ。
セッションに継続を使うのは、イベントハンドラから別の画面に 遷移した後で、もとの画面に戻ってくる時に、イベントハンドラの 元の場所に戻ってきたいから。 上手く行くかどうかは、あまり深く考えてない。
継続を使うのは、リクエスト毎に、復元と保存が一回ずつだけなので、 速度的なコストはたいしたことないだろうけど、メモリ食いそうだな。
_ Google AdSense
日記にも入れてみた。
_ 継続
とか言ってる間に、継続自体がばっさり削除されそうな予感
_ mod_securityでreferer spamよけ
1000以上もくらっていたので、こんな感じにしてみた。
SecFilterSelective HTTP_REFERER "foo|bar|baz"
fooなどの部分はアレな単語で置き換えてください。
いや、削るつもりは(まだ)ないんだけど。<br>なんか制約をつけたら安全になるかも、とは考えてます。<br>問題はどんな制約が妥当かわからない点。
robustでないイテレータを実行中には、callcc禁止フラグを立てるとかですかねえ。