■

Seasideなどの継続サーバーについては、IBMの素晴らしい記事があります。
http://www-06.ibm.com/jp/developerworks/java/060412/j_j-cb03216.shtml

Web開発において、HTTPはステートレスなプロトコルです。
それを、継続によって、開発者がステートフルに扱えるようになるというのが、面白いところです。

ところで、もし、
http://www.google.co.jp/
http://www.google.co.jp/search?&q=hogehoge
といったURLを、そういう名前の関数だととらえて、入力にStringをとり、HTMLを出力するのだと考えたらどうでしょう。
そうすると、HTTPがステートレスというのは、副作用を使えない関数型プログラミングにも似てきませんか。
そんな与太話はいいとして、

Seasideの開発者の、Avi BryantのBlog。興味深いことがよく書いてあります。
http://smallthought.com/avi/
継続についての随想もありました。
http://smallthought.com/avi/?p=14
それによれば、

  • Need quick response, but don’t need back button or bookmarking: AJAX
  • Need back button, don’t need bookmarking: use continuations/callbacks
  • Need bookmarking or other external access: use REST
  • 小気味よく動いてほしい、そのかわりブラウザのbackボタンとブックマークはあきらめる: Ajax
  • backボタンは使いたい、しかしブックマークはあきらめる:継続/コールバック
  • backボタンとブックマークを使いたい:REST
  • アプリケーションをひとつの巨大な状態機械と看做し (有限とは限らない)
  • その全ての状態にURIがついていて、
  • 各状態 = サーバーから送られるドキュメント、であり、
  • 状態遷移 = クライアントがURIを選んでリクエストを出すこと、である。

というのがRESTの見方である、と私は理解しています。

RESTは規模が大きくなるとコードが汚くなりがちなので、できれば敬遠して、継続やAjaxでどうにかしたいというのが現在の状況。

Strongtalkというのも後でみてみよう>自分。
http://strongtalk.org/