编者按：阿尼尔·达什是我们所认识的最聪明的人之一，也是现代科技的预言家，所以当他说出来的时候，我们很想听听他的看法。今天他谈论的是googlewave及其采用的障碍。

GoogleWave是一套令人印象深刻的技术，是一款让人目瞪口呆的光滑应用程序，它让开发者起立欢呼。我玩过一点GoogleWave测试沙箱，虽然它肯定太复杂了，无法达到“这将取代电子邮件！”它的发布引起了人们的大肆宣传，当然它有一些很酷的特性。因此，最大的问题是Wave能否成为一种流行的网络通信标准，因为Google在记录底层平台并使其足够开放以供其他人构建和扩展方面做出了令人钦佩的投资。我认为答案是否定的，原因是Wave方式与Web方式不兼容。

我所说的“网络方式”是什么意思？嗯，如果我们回顾一下扩展网站和加强交流所采用的新技术的历史，我们会看到一些趋势出现：

• 对网络的升级是增量的。不需要对你的技术基础设施进行彻底的改革，也不需要对现有的行为进行根本性的改变，获胜的web技术通常是那种可以零碎地采用、根据需要集成或作为更新网站或应用程序的正常部分的技术。
• 了解新技术需要一个周末大小的问题。对于许多web开发人员来说，在他们开始将新的协议或平台集成到工作中之前，他们会在一个漫长的周末整理一个粗略的演示，以确保他们真正掌握它的工作原理。在个人网站上的周末规模的实现通常在业务环境中大致转化为90天的实现周期，这是一个合理的可接近的项目规模(在科技领域，三天的个人努力往往转化为三个月的公司努力。）
• 在每个人都升级之前必须有价值。这基本上是梅特卡夫定律的推论。虽然我们知道网络随着节点的增加而增值，但网络技术的本质是，为了有价值，它必须提供价值，即使另一端的人没有升级他们的软件、网络浏览器、客户端或服务器。否则你就在一个空房间里大喊大叫。
• 你必须能够理解和解释它。嗯。

现在，如果我们看看一些成功的例子，我们可以看到各种成功的技术是如何展示这些特性的。一个很好的例子就是feed。当RSS源是新的时候，很容易立即理解它们的潜力，因为当时我在一家报纸工作，我只花了一个下午的时间了解格式，并拼凑出一个任何人都可以订阅的标题的快速提要。如果还没有人采用feedreaders，那就没有问题了，因为没有订阅者的feed也没有成本，“无人升级”的问题只会导致我浪费几个小时。

Ajax也有类似的采用模式。理解起来要多花一点时间，但不超过一个下午，向应用程序添加Ajax增强所需的开发工作从一个周末规模的项目开始，只是随着时间的推移而减少。遵循渐进增强的原则，设计良好的实现在不能处理新功能的旧浏览器或系统上表现良好。大多数添加了Ajax功能的网站都是通过在正常的持续更新过程中将需求作为检查表项添加的，而不是作为迁移到新技术的独立工作。

这让我们来挥手。Wave为扩展其核心功能和丰富其“小波”提供了极好的机会，我对其作为第三方可以建立的开发平台的实用性没有任何批评。但是，我担心，基波协议有点太复杂了，除了谷歌之外，任何人都无法完全正确地实现。互操作性很可能是困扰整个平台的一个挑战。简言之：很可能没有人会构建一个完全兼容的Wave克隆，与谷歌自己的实现竞争。

为什么是这样？让我们看看Wave的内置功能：

• 强大的实时协作功能
• 内容的无限制版本控制
• 围绕XMPP构建的健壮协议
• 结合聊天、文档编辑和消息线程-Wiki+博客+评论+即时消息
• 作为一个非常完善的丰富用户界面提供

每一个都是一个非常引人注目的经历。但很多开发者看到它们的反应不仅仅是“我等不及要用它了！”但也“我想把这个特性添加到我自己现有的应用程序中！”。这就是困难所在。让我们看一下Joe Gregorio的《浪潮》协议列表。乔在谷歌工作，但他在Wave工作之前就列出了这个名单。我赞赏他在这个问题上的研究和开放性，在这里介绍他的工作是对Wave伟大的贡献，而不是对他的努力的批评。）

• 联邦（XMPP）
• robot协议（JSONRPC）
• 小工具API（OpenSocial）
• wave嵌入API（Javascript）
• 客户机-服务器协议（由GWT定义）

真是太多了！XMPP本身就是一个需要实现的负担，更不用说大规模部署了(我想不出除了Google、Earthlink和LiveJournal之外，还有谁能为数百万用户部署XMPP。）但如果你想**另一个真正能与Wave所能做到的所有功能互操作的应用程序，那么将所有这些功能结合起来只是一个起点。

而且人们也不想用电子邮件、即时通讯、博客或维基来替代。这些工具都能很好地实现它们的预期目的，无论是什么技术增强了它们，都可能提供与那些系统不同的持久性和即时性的组合。现在，Wave唤起了所有这些，却没有成为它自己独特的东西。这意味着它在提供特定新特性的参考实现时最有用。

如果开发人员想要Wave的一个引人注目的特性，比如近实时协作，他们更可能使用（等待它…）按钮技术。按钮平台的组件所提供的基础设施远不及googlewave所展示的丰富多彩。按钮的设计甚至不能提供Wave所展示的好处。但值得赞扬的是，PuttonButton在互操作性需求方面远不及Wave的复杂性。更重要的是，将按钮功能集成到网站或应用程序中并不是构建几十个尖端功能的单一过程，而是可以由非专家的网站管理员逐步部署。

在这种情况下，将按钮技术视为“微波”可能会有所帮助。正如Gina Trapani提到Google Reader对PubSubHubBub的支持时所说：

啊什么？你问吧。是的，我知道。这不是谷歌浪潮。但这才是让人兴奋的地方。这种小型按钮实现是真实网页如何轻松地使用现有技术通知彼此新的更新。googlereader/FriendFeed的集成只是广泛部署实时站点的第一小步。这些网站和服务将让彼此知道何时有新的数据可以共享，而不会出现糟糕的低效率投票。在上面的视频中，当你在googlereader**享一个项目时，看看FriendFeed的更新速度有多快。

简而言之，它几乎是零延迟。

为什么这种明显“劣质”的技术会胜出？作为一个例子，XMPP对于任何普通人来说都太复杂了。然而，如果您正在阅读这篇文章，您可能已经可以访问一个常规的httpweb服务器，该服务器可以与hub进行通信。事实上，我所知道的唯一两个与XMPP有广泛合作的支持者是布拉德·菲茨帕特里克和阿图尔·伯格曼，他们共同创建了Djabberd。他们都对pubsubbub很兴奋。实际上，像Yahoo这样的人可能会尝试做所有这些，不可避免地，一个或两个开源项目会尝试将这些部分的开放实现捆绑在一起，形成一种FrankenWave应用程序。可能已经有一两个团队在不可避免的“EnterpriseWaveServer”平台上工作了，尽管我自己还没有听说过。这些努力可能会成功，但这并不意味着它们会足够强大，人们会信任它们在网络上进行交流。

更重要的是，我是一个经常写博客的人，对在普通web服务器上编写脚本略知一二。我可以浏览文档并对我的RSS提要进行一些调整（或者，在我的情况下，什么都不做，让Feedburner自动为我处理），突然间，我的博客提要就成了Pushbutton web的一部分，可以让其他人在上面构建。如果我想在一个漫长的周末将Wave开发者文档与我的网站或任何我喜欢的小应用程序集成，我甚至不知道从哪里开始。似乎更现实的是，有人会想出一种方法，在实时反馈的基础上逐步构建，以实现类似波浪的体验，或者所有这些关于波浪、小波和光点的讨论会突然变得容易理解。

简言之，像feed、Ajax和Pushbutton这样的web技术之所以会胜出，是因为那些**好网站和应用程序的人有一个起点。这是不是意味着我们马上就可以进行实时编辑了，现在按钮已经存在了？不。事实上，Wave甚至可能在web应用程序的这些功能上获得早期飞跃，这仅仅是因为它开创了用户体验的这一部分。但是Wave只能在最前沿的web浏览器上充分发挥其潜力。世界上可能只有十几家公司拥有克隆Wave技术的内部专业知识，以便成为一个成熟的竞争对手。更糟糕的是，Wave体验的单一性意味着，要想成为正式的Google服务的开源竞争者，这甚至是一个挑战。

我希望Wave成功，因为我喜欢看到雄心壮志和创新得到回报。但我认为Wave最有可能的成功在于通过在现有网站上添加增量增强功能来激励人们创造类似的引人注目的体验。在过去，网络总是这样进步的。

工作原理：Web方式与Wave方式[Anil Dash]

Anil Dash在Dashes.com上写博客已经超过十年了，在预测下一步会发生什么方面有很好的记录。你可以订阅他的RSS提要或者在Twitter上关注@anildash。