Hatena::Groupangelos

Angelos in Action RSSフィード

Fork me on GitHub
 | 

2009-09-05

PSGIまとめ

04:13 | PSGIまとめ - Angelos in Action を含むブックマーク はてなブックマーク - PSGIまとめ - Angelos in Action PSGIまとめ - Angelos in Action のブックマークコメント

PSGIのレイヤではWSGIと同じでプロトコルだけ決めて、Request, Responseなどのクラスとしてのインターフェースは決めない。PlackはPSGIの仕様に沿った実装で、PlackXはWAFとPlackを繋ぐための拡張でPSGIの仕様範囲外の実装。

# irc logの大体のまとめ

# YAPCの発表練習しないとと思いながら完全に現実逃避中ナウ...さすがに眠いので寝ます...

アプリもPSGIプロトコルでcallしてほしい!

03:06 | アプリもPSGIプロトコルでcallしてほしい! - Angelos in Action を含むブックマーク はてなブックマーク - アプリもPSGIプロトコルでcallしてほしい! - Angelos in Action アプリもPSGIプロトコルでcallしてほしい! - Angelos in Action のブックマークコメント

PSGI化された後のHEで自分のイメージとあわないのは、ReqつくるところとApp(WAF)側でできないところなんですよね。上手く伝えきれてないような気もするので、少しまとめておきます。

WSGIだとアプリケーション側(WAF)もWSGIの仕様にそっていて、WSGIプロトコルアプリケーションが呼ばれます。なので、Requestの生成部分についてもアプリケーション(WAF側)の制御範囲になるので、このほうがWAF開発者にとってはいい仕様なんじゃないかなぁと思ったり。

以下がイメージです。 

Apache2
↓
PSGI::Impl::CGI
↓PSGI Protocol
PSGI::Middleware::DebugScreen
↓PSGI Protocol
Angelos::WSGI::Application
↓Angelos::Request
Angelos::Dispatcher

最後の部分は、以下のような感じで、envが渡される。

$app->call($env);

WAFのapplicationクラスのcallメソッド内では、

sub call {
   my ($self, $env) = @_;
   my $req = Angelos::Request->new($env);
   return dispatch_request($req);
}

リクエストは、リクエストビルダーとしての機能はRequestクラスを継承することで実現できると。

Angelos::Request extends ( PSGI::Request or HTTP::Engine::Request)

merb, railsの実装はこうなっているためRequestの拡張をWAF側で行うのが簡単なので、これは結構いいなぁと思ってます。

要するに、アプリケーションWSGIプロトコルでcallできるようになっていて、Requestの生成ハンドリング部分がアプリケーションにまかされているからいいなぁと。

それと、Requestは単純に作るのが面倒なのでユーティリティとしてPSGIかPSGIxのようなもので提供する形がいいんじゃないかなぁと。PSGIはプロトコル仕様であって、Requestを含めるべきではないという意見もあるかもしれないんですが。その場合は、PSGIxのような形で提供されるといいなぁと。

結論としては、以下のいずれかになるとWAF開発者的にはありがたいなぁと思いました。

  • PSGI::RequestをPSGIから切り離す場合、HEのインターフェースを追加してrequest handlerだけじゃなくてPSGIプロトコルでApp(WAF)のhandlerをcallしてくれる仕組みを用意する
    • 例えば、HEのinterfaceでrequest_handlerだけでなくて、psgi_handlerを渡せるようにするとか。
  • リクエストビルダーをPSGI or PSGIxなどで用意する

上記のいずれかであれば、WAF開発者的にはそれなりに拡張が用意にできるんじゃないかなぁと。

こうなっていると、Server Gatewayの開発者はWSGIの仕様にのっとってシンプルなインターフェースで開発ができ、WAF開発者もWSGIプロトコル仕様に乗っ取りWAFのアプリもMiddlewareのようなものとして扱われ、WSGIプロトコルで呼ばれ、Requestの生成をControlできるようになって、全員幸せなんじゃないかなぁと思うのです。

# 自分のRack, WSGIの理解は上記のような理解なんですが、それは違う!ポリシー的にこうすべきだ!みたいな話があれば教えてもらいたいなぁと。

HTTP::Engine isn't dead but ...

20:34 | HTTP::Engine isn't dead but ... - Angelos in Action を含むブックマーク はてなブックマーク - HTTP::Engine isn't dead but ... - Angelos in Action HTTP::Engine isn't dead but ... - Angelos in Action のブックマークコメント

HEはReq/Resレイヤで処理して、Req/Res変換以外の処理はPSGIに処理を委譲って形になるのだろうなぁと。そうすると、PSGI側にRackの処理がそのまんまうつるとenvのprotcrolとreq/res変換だけがHEの仕事になって、HE自身はすごい薄いwrapperになるんじゃないかなぁと。

そして、WAFを作りだすと自前のRequestをつくりたくなるので、WAF開発者は結局PSGI直接つかうことになるんじゃないかなぁと。例えば、HEでrequest_classを指定して、Requestが拡張できたりとかHEのレイヤで工夫が出来ないと、WAF開発者はHEのReq/Resに縛られちゃうので、PSGIのレイヤで扱いたくなるんじゃないかなぁと。

さらに、PSGIができると、WAFの提供者はreq/resレベルのHEMのreq/resのミドルウェアではなくて、PSGIのミドルウェアを提供するようになると思うんですよね。PSGIのほうがより多くのWAFにMiddlewareを提供できるようになる可能性があるので(ここが本当かどうかというのは、Rackをみていると微妙な感じもするんですが)。要するに、HEMは不要になっちゃうんじゃないかなぁと。

なので、WAF開発者の視点でHEをみると、

  • request classが差し替えられて(もしくはduck typeで)
  • HEに対して、HEのMiddlewareだけではなく、PSGIのミドルウェアも設定できる

ようになっていれば、PSGIができてもWAF開発者がHEを使うようになるんじゃないかなぁという気がしてます。

これは、WAF開発者的にそう思うんじゃないかなぁという話で、アプリ開発者がPSGIをつかってアプリを作りたいと思うかというと違うだろうなぁと思ってます。HEが死ぬということがいいたいわけじゃなくて、WAF開発者としてHEを使うには、多分少し機能を追加する必要があるんじゃないかなぁと思うんですね。

# Req/Resレイヤで提供するServletのようなものがメインになるのか(今のHEのように)、WSGIのようなlow levelなプロトコルがメインになるのかという話があるのと、WAFレベルではどのレイヤの拡張を提供するべきなのかという話もあって、一概にHEMが不要という話でもないかもしれないというのは思っていて、この辺はあまり解がないような気もします。ただ、WSGIとかRackみてると、req/resレイヤのMiddlewareではなくて、WSGIのMiddlewareになっちゃうんじゃないかなぁという気はするんですが。

PSGI

12:32 | PSGI - Angelos in Action を含むブックマーク はてなブックマーク - PSGI - Angelos in Action PSGI - Angelos in Action のブックマークコメント

http://bulknews.typepad.com/blog/2009/09/psgi-perl-wsgi.html

http://d.hatena.ne.jp/tokuhirom/20090904/1252091316

Rackをまるっとコピーして、一部Perlらしくなおして、HTTP::EngineをPSGIのラッパにする感じになるのかなぁ。HTTP::Engineのrun部分だけが残って、MiddlewareはRack風に作り直すことになるだろうなぁと。プロトコル部分だけ決まれば、Rackみたいに仕様はシンプルになるし、作る人が増えるかもしれないですね。

PSGIがそういう形になると

という形になるかなぁと。PSGIダイレクトに使えば、WAF側でリクエスト用意したりも簡単ですし、WAF作者的にはありがたい流れかなと。全体的には仕様もかなりシンプルになりどうだしいいなぁと。

後は、PSGIのレイヤは、特定のアクセッサへの依存をなくせば、汎用に使われる物になりうるんじゃないかなぁと。To Moose or not to Mooseみたいなカオスも避けられますし。

# 幸いトーク内容には、HEMの話は入ってないのでスライド修正はいらないかなぁと。危ないw

 |