小半年前，和做IM的同事討論web IM的ajax實現(xiàn)的時候曾經(jīng)提起過這樣一種做法：維持一個http長連接來等待后臺的聊天數(shù)據(jù)，當(dāng)聊天數(shù)據(jù)一到就立刻把數(shù)據(jù)發(fā)送進(jìn)這個http連接里面并斷開連接讓xmlhttp開始解析，這樣就可以做到客戶端對數(shù)據(jù)的即時響應(yīng)。這一就是“推模型”的ajax版本。
其實當(dāng)時我們也懷疑meebo等web IM有可能已經(jīng)采用了類似的技術(shù)，但是未經(jīng)確認(rèn)。由于考慮到IM部門有可能需要把這個技術(shù)申請專利加以保護，因此很長的一段時間里面不管是論壇上還是blog上我都沒有提及過這個想法。
今天偶然在網(wǎng)上發(fā)現(xiàn)了一個叫做comet的技術(shù)（http://alex.dojotoolkit.org/?p=545），和我們的想法如出一轍，現(xiàn)在已經(jīng)至少被應(yīng)用在：
GMail’s GTalk integration
Jot Live
Renkoo
cgi:irc
Meebo
消息遲鈍到如此地步，汗顏中。
奇怪的是，似乎comet技術(shù)不需要斷開http連接，不知道是如何讓xmlhttp控件開始解析數(shù)據(jù)的（如果不用xmlhttp技術(shù)的話，那不就成了傳統(tǒng)的“推模型”了嗎？）。
