Comet: Low Latency Data for the Browser
历史深处的一种古老的web technology正在慢慢复兴。已经多年未被触及的浏览器特性又一次登上了web开发的舞台，为UI带来了更好的响应。Server正在学习如何应付一种新的行事方法。并且，我说的不是Ajax。
像Jot Live和Meebo这样的新兴服务使用了一种新的数据传输形式，既不是传统的数据传输也不是Ajax。它们的招牌特点是数据传输的low-latency，而这种特点正变得越来越普遍。由于没有更好的术语，我把这种event-driven的、server-push data streaming的形式叫做“Comet”。它不代表任何意义，况且我也不觉得它应该代表什么。这种technique的工作原理可能会使开发人员十分困惑，所以使用已经存在的定义和名字很可能会产生不良的效果。
定义Comet
为了使用新的术语，我们至少要看一些该技术的实例，被该技术解决的问题，以及使它与众不同的特性。这些实例并不难找，几个典型的实例是：
<!----><!---->GMail’s GTalk integration
Jot
Live
Renkoo
cgi:irc
Meebo
究竟是什么使这些应用与众不同的呢？究竟是什么使它们有别于那些乍看起来十分类似的应用呢？本质上的区别就是，它们都使用long-lived HTTP连接来降低server传输的信息的延迟。它们不会时不时地从server端poll信息。相反，server会维护一个通信的开路，这样它就可以把数据push到client了。
从网络活动的角度上看，我们可以修改JJG的原始Ajax图来说明Comet的不同之处：
如同上面图例所示，Comet应用可以在任何时候向client发送数据，而不是仅仅在用户输入的响应中发送数据。这些数据从一个单独的、预先打开的连接中被传输。这种方法极大地降低了数据传输的延迟。
这种架构基于对数据的一种新的认识，即数据在HTTP连接两端都是event-driven的。熟悉SOA或message-oriented中间件的工程师会发现这副图与它们出奇地相似。唯一的改动就是这里的终点是浏览器。
虽然在异步性方面Comet和Ajax很相似，但是实现了Comet的应用能够在几乎可以忽略的延迟下通信状态的改变。这使它非常适合监控和多用户协作类型的应用，如果没有Comet，这些应用将很难或不可能实现，除非在浏览器中添加插件。
为什么对用户来说Comet更好？
常规的Ajax提高了单个用户的UI响应，但其代价是使long-lived页面的内容变得“陈旧”。其他用户执行的数据改动是看不见的，直到用户刷新整个页面。应用也可以回到“旧社会”去，维护某种状态机制，告诉client从上次通信到现在的所有改动。用户不得不要么执行某个操作来请求查看其他用户更新的状态（这也许会对它们想要执行的操作造成影响！）要么每隔一段时间就向server请求改动信息（叫做“polling”）。因为web天生就是多用户的，所以很明显，常规的Ajax在usability和transparency hurdles上欺骗了用户。使用Comet技术的应用可以避免这个问题，它可以在更新发生时主动push给所有的client。UI的状态永远是同步的，使用应用的每个人都可以轻易理解他们的改动会影响其他用户。Ajax提高了单个用户的响应。Comet提高了协作的、多用户的应用的响应，并且避免了轮询所带来的性能问题。
但它会流行起来吗？
为了使Comet应用流行起来，新的server软件通常是必须的，但是服务器端的event-driven IO模式正变得越来越广泛。甚至连Apache都会在下一个版本2.2中提供Comet模块。在那之前，Twisted、POE、Nevow、mod_pubsub，以及其他高层次的event-driven IO抽象正使得站在技术前沿的开发人员可以使用Comet。几乎所有的现代OS也已经支持了某种内核级别的event-driven IO系统。我甚至听说Java的NIO包将会在下一个版本中利用这些系统。这些工具正悄悄地把event-driven的未来变为现实。Comet会流行起来，并且大多数工具已经可以使用了。
我会在ETech上再次讨论这个话题，并会描述Comet应用可以用来从server端向client端 push数据的各种技术。和往常一样，我也会把slides发布在我的Blog上。
Read-write web的未来是多用户的。Ajax之后还会有另一种生活。
尾注
略