世界線航跡蔵

Mad web programmerのYuguiが技術ネタや日々のあれこれをお送りします。

2006年01月06日

Ruby/AJP開発記(3)

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好きだし。

トラックバック

http://yugui.jp/articles/337/ping

現在のところトラックバックはありません

コメント

blog comments powered by Disqus

ご案内

前の記事
次の記事

タグ一覧

過去ログ

  1. 2016年07月
  2. 2016年01月
  3. 2015年09月
  4. 2015年08月
  5. 過去ログ一覧

フィード

フィードとは

その他

Powered by "rhianolethe" the blog system