はじめに
こんにちは、Python界の情弱クレイジー野郎です。この間Armin Ronacherが書いたWSGIに関する記事から、あちこちでWSGIに関する議論が起きてますが、とりあえずその返答記事として書かれたWSGI Liteに関する記事を訳しました。
WSGI Is Dead: Long Live WSGI Lite!
ほぼ10年前、Web-SIGにはじめてWSGIのアイデアを提案したときに遡ると、WSGIがどう「フレームワーク分解機」になり得るかということに対して、私はいまよりもずっと理想主義的な展望を期待していました。すべてがプラガブルで、モノリシックなアプリケーションフレームワークを持つ理由がもはや一つもないような未来を思い描いていました。すべてライブラリ、ミドルウェア、デコレータでまかなえるからです。
悲しいことに、そんな理想的な未来はやってきませんでした。事実、2007年の時点で、私は上手くいっていないことがわかっていました。そしてWSGI 2プロトコルのアイデアを提案したのです。それで問題は解決するはずでした...それから数年、結局何もしなかったのです。（とはいえ、私は他のことをしていたんです。たとえば、setuptoolsとか、Chandlerとか、仕事とか。ただウェブアプリケーション、つまりWSGIのことをしていなかっただけなのです！）
とにかく、先週、Armin Ronacherがこの話題に関して "WSGI and the Pluggable Pipe Dream （邦題：WSGIとプラガブルパイプという夢）" という素晴らしい記事を書きました。もしまだ読んでいなかったら、是非一読することを強くお勧めします。WSGIの重箱の隅や設計に関する決定について数多く深堀した内容が書かれています。そうした内容は元々の設計に関わっていない人々やWSGIを使って仕事をした経験が浅い人には広くは理解されていません。
しかし、Arminの記事の最後には少しがっかりしました。Arminの宣伝記事を読んで、彼が start_response, write, close, その他WSGIミドルウェア内にある全てのCRUD操作を扱う中で起きる問題に対して、何らかの解決策を持っていると信じていたのです。
しかし実際は彼の記事は、例え誰かがWSGIより良い何かを発明しても、既存のWSGIプロトコルに対する財産が多いため、それを置き換えるものはないだろう、と締めくくっていました。
だから、私は「何かしてやろう」と決めたのです。
WSGIの新しい弟分、WSGI Liteを紹介します。
WSGI Liteは私が4年前に提案し、他の言語のWSGIが使っている規約とほぼ同様である"WSGI 2"と基本的には同じものです。start_response, close, write, exc_infoといったややこしいものは一切無く、またpost-requestのリソースの開放や操作の後片付けなどを管理する上で大々的に改良された方法を導入しました。
いま、もしWSGI LiteがただのWSGI互換だとしたら、Arminの記事は正しいでしょう。つまりWSGIの競合になるため誰も使わず、それを置き換えるためには基本的には「すべてを、、停止、、」しなければいけません。
しかしWSGI Liteプロトコルは実際はWSGIの後方互換です。WSGI Lite API向けにコードを書いて、透過的に既存のWSGI対応のサーバ、アプリケーション、ミドルウェアとやり取りできます。
それはつまり、なにも置き換え無くていい、ということです。適切だとか役立ちそうだとか思ったら、いつでも使い始めてください。
必要なのは2つのデコレータだけです。1つは"lite"アプリケーションであると宣言するためのもので、もう1つは"lite"呼び出しプロトコルを使った標準WSGIアプリケーションを呼び出せるようにするためのものです。（そして特別ボーナスとして、新しいコードに使うデコレータは自動的に環境キーやセッション／リクエストオブジェクトや他のいい感じのものをアプリケーションやミドルウェアのキーワード引数に束縛してくれます。とってもスタイリッシュです。）
WSGI Liteが「プラガブルパイプという夢」を復活させてくれる事を願います。そしてWSGI Liteによって夢ではなく、実際にパイプとなることを願います。
実際にためしてみて、あなたの考えを教えて下さい。
追記
記事を翻訳してすぐ公開したので、実際にWSGI Liteがどんなもんか見てなかったんですが、これはArminの記事が書かれてから実装されたみたいですね。greenlet使ってたりなんだりで、微妙な部分もあったりしますが、そのへんはきっと id:mopemope が書いてくれると思います！
