みかログ

JavaScriptベースのチャットを作るとき，Cometを使うのが一般的とされているようだけど，もっと楽な方法でも良さそうに思える．

Cometでは1回リクエストを受け取るたびにコネクションを切断しているので，Keep-aliveなどと併用しなければならない．
実際に都度TCP接続を張り直すとコストが大きいので，Keep-Aliveを併用したりする必要があるものの，それも色々裏技的な回避をしないとだめな模様．
（Cometの正しい使い方を参照）

でも，チャットを実装する上では，都度コネクションを切断する必要がなさそうに思える．
iframeで別のページを読み込み，その中で script タグを使って親フレームを更新するだけではダメなのだろうか．

この方法であれば，
・Cometのように，切断してから再接続するまでのタイムラグがないので，サーバ側の余計な処理が減る．（切断中に届いたメッセージを探す動作などが不要）
・サーバに再接続しないので，サーバ側からのpushが連続したときでも余計なタイムラグが発生しない．
・Keep-AliveやPipeliningなどとの相性問題の心配が不要
といった点でメリットがありそう．

実際にサンプルを作ってみると，
chat.html
chat.cgi (ソース)
こんな感じでちゃんと動く．

ただ，Comet+JSONPならメインのドメインとは別のドメインで接続が出来るけど，この方法ではクロスドメイン制約にひっかかって無理．
しかし，ページ自体を複数ドメインにすれば簡単に回避できるはず．
（チャットルームごとに http://部屋名.example.com/ のURLを使うとか）

Cometのメリットがこれだけなら，多くのケースでは接続しっぱなしの方が実装も楽で良さそうに思うけど，何か見落としているのかなぁ？
Cometのページを見ても，その辺に関しての記述は見つけられなかった．．．

それとも，Amazonアフィリエイトみたいな事をやろうとするときに，メインのページが固定ドメインでないと不都合がありそうなので，そこが重要だったりするのだろうか…
（とりあえず気になったので，Amazonに http://*.example.com/ のような形で登録できるか聞いてみた．返事待ち）

----

追記．

今更1つ大きな違いに気づいた．
iframeでは，ブラウザのロード中の表示が継続してしまう．
IEだとあまり気にならないけど，Firefoxとかでは結構気になる．

Cometであれば，見た目は変わらないので，やっぱりそこがメリットなのかな．

GmailもどうやってるのかFirebugで見てみたら，Cometっぽい感じだった．
だいたい200秒くらいでタイムアウトして，新しく接続し直している感じ．

----

さらに追記．

久しぶりにはてブを見てみたら，コメントがあった．

throbber が回ることさえ気にしないのなら、それでOK。切断時の対応コードを含めると、コード量はかわらないと思う。iframe なら document.domain 操作でサブドメイン越えが可能

とあった．

まぁ，ぐるぐる回るのは一度気づいてしまうと気になって仕方ないので，無しかなぁ．