#テスト
#proxyの中なので、rfc/http.scmをごにょごにょ
#chaton-watcherjno
#s/jno/の/
#observeの[(and-let* ... のclause要りますか？
#というか、あるとarchive直後のをとりこぼさないかな？
#んー、可能性として取りこぼしはあるかなあ。
#この節がtrueになるのはtruncateが起きた時なんですが、その場合、truncate後のcurrent.datの内容が全部送られてくるんですよ。
#最終発言のタイムスタンプを持っておいて比較すればいいのか。
#意味を考えると、truncateが起きたときに新しいcurrent.datの内容を全部送るっていうのは、まあ妙な仕様ではあります。
#あそうか、archiveしても重複があるのか
#単にweb interfaceで表示させるときに、それが楽だった (truncateが起きてたら内容を全部入れ替えるだけでよい) というアドホックな理由なんで。
#差分を送るメッセージと、currentを送り直すメッセージをわければいいのかな。
#ですかね。clientによっては重複のないデータがほしい場合もありそうですし。
#あと、chaton-watcherをtail -fのようなviewerだと思うと、chaton-connectでposが指定できるといいかも
#0以外の値の意味は微妙ですが
#> proxyの中なので、rfc/http.scmをごにょごにょ
#というのは?
#rfc/http的には、proxyへの対応は上位レイヤの仕事 (serverにproxy serverを、resource-uriに最終目的のurlを、callleeが渡してやる) という感じのつもりなんで、
#chaton.clientのproxy対応ならばchaton.client側でごにょごにょすべきかな、と。
#80と9997とhttp-get二か所あるとなぜか思い込んでいたのが、ひとつ。
#ちなみに、proxy対応を上位でやる場合は、redirectも上で処理することなります？
#む、proxy+redirectのコンボは考えてなかった。
#そうか、proxyが噛んでる時は3xxのlocationのuriに直接redirectしたらいかんのか。
#だとするとrfc.http内でproxyの処理もやるほうが綺麗かなあ。
#rfc.httpの上が直にアプリケーションの場合も多いのだとしたら、proxyの処理は下でしてくれたほうが便利かなあ、と思います。
#当初は、rfc.httpはhttpのプロトコルを生で見せる低レベルなライブラリで、その上にnet.httpという便利ライブラリを作るという予定でした。authenticationとかcookieの自動ハンドリングなんかもnet.httpのレベルでやろうかと。
#でも、たとえばpersistent connectionはrfc.httpのレベルで扱うべきだろうし、そうするとそのコンテキストにauthenticationとかcookieとか詰め込んでもそんなに不自然じゃないしなあ、と最近は思っているので、rfc.httpをリッチにする方が良いでしょうね。
#ひとつ上位のレベルとして、rubyのopen-uriだっけ、いろんなプロトコルを包括するインタフェースはつくろうと思ってます。
#test
Chaton > Archives > 2009/05/29