Server側ライブラリの設計、考えれば考える程自信が無くなってくる。
サーバー処理の流れへのユーザーコードの挿入はどうするのがセンスがいいんだろう。Procを属性値に設定するか。ほとんど同じことだけれど、ブロックで渡すか。同じブロック渡しにしても、Railsみたいにクラスメソッドにしてクラスの宣言みたいな感覚で使ってもらうのがいいのか、それともインスタンスメソッドにして無用にクラスが増えないようにするか。どうせ使用時にサブクラス化するなら、Template Methodパターンにしてしまうか。
ユーザーコードでforkする可能性も考えないといけない。その場合でも、子プロセスを確実にwaitするためにあんまりlambda, lambdaしたユーザーコードを要求したくないしね。lambdaもcontinuationも個人的には大好きだけれど、でもライブラリ設計としてはもっと敷居の低いAPIでありたい。
考えてみると、サーブレットのためのライブラリは書いたけれど、サーバーとかデーモンとかそういうものも色々書いたけれど、、「サーバーの骨格それ自体を作るための」ライブラリっていうのは初めて書くのだなぁ。
Railsアダプタとか、アプリケーションサーバーとかはもう1つ上のレイヤーで提供することにして、このレイヤーでは純粋にAJP1.3をRubyの世界のメソッド呼び出しに翻訳するにとどめたいからこその苦悩ではある。0.2の目標はRailsへのアダプタの提供であるけれども、今取り組んでいるレイヤーとアダプタを密に結合してしまえば答えは簡単である。でも、それはしたくないのだよね。AJPが定義するパケットのやりとりというレベルとRails定義のクラスを使用するレベルは交錯させたくない。
追記
SCGI Ruby on Rails Runner はTemplate Methodパターンか。やっぱりこれがユーザーにとっては「驚き最小」で良いのかな。考えてみれば、RailsへのアダプタではどうせThread使うし、forkしたときの面倒はユーザーに自分でなんとかしてもらうってことでAPI決めちゃっていいか。
Threadといえば、今まで書いた一番大きいサーバープログラム(C+inline asmだった)では、「スレッドはQuiche Eaterが使うものだ。真のプログラマはselectを使う」（意訳）と言われてselectで書くことになったけれど、Rubyのスレッドはselectなんだよね。どうせ私はQuiche好きだし。
