第一代搜索引擎所代表的是“整合互联网静态信息”的愿景，Google借助其强大的搜索引擎和海量存储成功的树立了搜索领域的霸主地位。在这个年代，整合互联网信息的方式相对比较直接了当，那就是“蜘蛛+索引+搜索”。大部分静态内容都是可以方便的直接访问到的，因此Google只需要构建一个巨型索引就可以达到整合信息的战略目的了。

　　伴随着Web 2.0的迅速发展，互联网的主要构成已经由静态信息向用户贡献内容倾斜。越来越多的网站主要依靠用户发表或上传的内容主导，Google也因时而动的推出了一系列针对性的垂直搜索，例如Blog Search、Groups Search、Photo (Images) Search、Code Search。但是，Web 2.0的一个显著特征是社会化，这就造成为数不少的用户贡献信息并不面对搜索引擎的蜘蛛开放，尤其是各大SNS社区，几乎都主动屏蔽了搜索引擎。出于用户隐私的保护，其它信息形式，如照片、代码等往往也部分性的不开放给搜索引擎访问。另一方面，Web 2.0提供了更为结构化的信息，这些信息依靠蜘蛛的抓取很难保留其结构化的原貌。不断涌现的新情况让Google觉得相当的被动，于是它启动了一轮庞大的“信息控制战”，通过免费向用户提供有竞争力的各种信息的存储服务，达到将全球信息掌控在自己手中的目的。于是Gmail、Blogger、Picasa Web、Google Code便应运而生。但凡有其它初创型公司挡在了Google的战略大道上，便不客气的一口吞掉，比如YouTube、Writely。在如此强势的战略夹击下，Google在Web 2.0的时代勉强保持住了它在信息整合方面的优势地位，但面对Facebook、Twitter等新兴信息承载形式的崛起，却显得颇有些步履蹒跚、力不从心了。

　　在后Web 2.0时代，互联网对于大众的意义，已经逐渐从一个单纯的信息获取通道，转变为一个全能的服务平台，这在最近刚刚被提出的Gov 2.0中体现的尤为明显。交互应用开始取代信息媒体，成为互联网的主导力量，并剧烈的改变着互联网的面貌。尽管Google一直致力于推动数据开放化和API标准化，但互联网毕竟不是一家说了算，长尾的延伸，让Google执行其战略愿景的难度越来越大。搜索引擎的历史局限性注定其难以在新的互联网格局下继续担当整合全球信息的重任。首先，搜索只能控制用户在互联网行为的最初阶段，其快速的逸出性使搜索引擎很难像SNS那样掌握更丰富的用户信息；其次，交互应用取代单纯的信息呈现后，已经不再可能简单的通过搜索引擎体现其对用户的价值；最后，应用之间的Mashup使得互联网上信息的拓扑层次愈加复杂，搜索引擎扁平的索引方式已经很难有效整合这些信息。

　　在这样一个大背景下，Google开始酝酿其夺回战略主动权的新型武器，这就是Google Wave。表面上，如同Google所声称的那样，“Google Wave is an online communication and collaboration tool that makes real-time interactions more seamless — in one place, you can communicate and collaborate using richly formatted text, photos, videos, maps, and more.” Google当然不会直接告诉你Wave背后的战略意图，但无论是从开发资源投入、系统复杂程度、宣传推广攻势上，Wave都是空前的。其邀请机制的苛刻程度甚至超过了当年的Gmail（后者如今以成为Google除搜索外最引以为自豪的产品）。这些都充分显示出Google对于这款产品的重视程度。

　　其实，Wave API才是揭开Google Wave战略的关键。为什么Wave的Preview邀请明显倾向于开发者和合作伙伴？在Wave主体功能都尚未完成时，各类API和SDK却得到了优先的完善。显然，Google向第三方开发者频频伸出橄榄枝并不会单纯因为它同时提供API接口这么简单。下面就来细细解剖一下Wave API，看看这葫芦里究竟卖的什么药。

　　Wave API目前分为两个大类：Extension和Embed，前者相当于插件，为Wave扩充功能；后者相当于呈现包装，可以将Wave嵌入其它现有应用中。Embed的作用不用我多作解释了，而Extension则是Wave的战略核心。

　　Extension又可分为两个分支——Robot和Gadget，它们与Wave一起构成了应用开发中典型的MVC架构：Model是Wave框架本身，View是Gadget，而Controller则是Robot。Wave本身的三层数据结构（Wave-Wavelet-Blip），具有动态性、实时性、可交互性的特点，迎合互联网应用的Model设计需求。Gadget作为Rich Text等标准媒体类型之外的扩展接口，使Wave可以适用于各种特殊应用场合。而Robot则依应用形式的不同，可充当不同的具体角色：在封闭的Wave应用中，它们充当传统的Controller角色；而在Mashup的应用中，Robot则充当胶水，可以是Importer、Exporter或者是Transformer。

　　Wave API的一些设计理念也从一些侧面折射出Wave的战略愿景，比如：

• Robot也可以创建它的Private Wavelet，或者与其它Robot共享Wavelet。这些Wavelets对用户是不可见的，它们可以被用作Robot的持久存储，或是通信通道。
• 不可见Wavelet可以看成是一个支持事件通知的“通信通道”，其中的Blip则是单个“消息”。这给应用开发提供了充分的发挥空间，比如用作类似于Unix下的管道，实现应用搭桥；或者用作Provider/Consumer模型的任务分发队列；又或者用于选择性的组播；甚至是可修改的全局参数集。
• 可见的Wavelet则可以当作一个人机交互的接口，便于用户以一种类似对话和交互编辑的形式与应用进行交流。当然，借助Gadget，还可以扩充至任何需要的交互形式。

　　虽然整合目前互联网上的众多应用并不现实，但Google鼓励开发者通过Extension将应用的功能和接口嵌入到Wave中来，即Google所设想的“All in one place”。表面上，Wave像胶水一样，可以方便的将实现了Wave Importer和Exporter的应用Mashup。不过，当胶水成为事实上的标准之后，应用之间的竞争壁垒则被Google渐渐的填平。到那时，Wave便升华为运河，而你无论是摆渡者，还是商人，都只是在这条河道上碌碌奔波的营生者，时刻担心被竞争对手取而代之，只有这条运河本身，才是无法被取代的垄断者。

　　还记得很久之前曾经读过一篇科幻小说，描绘了一个“互联网的幻境”：在那里有各式各样的智能零件，每个人可以充分发挥想象力组装出各种或实用或有趣的器具来装点自己的小屋，整个幻境世界的公共设施也是由术士们（开发者）自发协作建设起来的，而那些Geek们则喜欢利用系统的漏洞玩一些“黑魔法”。

　　透过Google Wave，我似乎依稀看到了“互联网幻境”的轮廓……

Google在2004年“愚人节”推出的Gmail服务可以说是Google众多服务中，除搜索外最杰出的典范之一。Gmail在过去五年多的时间里，也经历了一个持续发展和演进的过程。新功能的推出和用户体验的改善或许是大家谈的最多的，但其底层架构的变迁却并不常常能被用户切实感受到。其实，正是因为Gmail底层架构的不断升级，才支撑其众多新特性和功能的更快开发并上线。

早在2007年10月，Gmail的官方Blog上就曾经发表过一篇关于其架构变迁的文章“Code changes to prepare Gmail for the future”，其中提到：

So recently the Gmail team has been working on a structural code change that we’ll be rolling out to Firefox 2 and IE 7 users over the coming weeks (with other browsers to follow). You won’t notice too many differences to start with, but we’re using a new model that enables us to iterate faster and share components…

这里第一次公开提到了“Iterate”，表明在新的架构下，Gmail的开发团队开始以迭代的敏捷开发模式进行着Gmail的维护和增量开发。

随后，在2008年5月，Gmail正式推出了一项让人耳目一新的功能，确切的是，是一系列新功能的入口——“Gmail Labs”。这这里，你可以选择性的激活你所喜欢的新特性，关闭那些对你作用不大或者不好玩的功能。这说明，Gmail此时的底层架构已经过渡到了成熟的模块化和前后端高度整合的程度。“Gmail Labs”可以看作是一个基于模块化架构的“插件平台”，使得新功能和特性可以以插件的形式开发出来，并由用户决定其想要的组合。

在后来2009年3月中Gmail官方Blog的一篇文章进一步揭示了“Gmail Labs”的一些内幕：

Every time a Gmail user signs in we create a custom version of JavaScript for them based on the Labs features they have enabled. Since we have 43 Labs right now, there are 243 (~8 trillion) possible versions of the Gmail JavaScript that a user could get. If you account for the 49 languages where Labs are now available, it gets even bigger — 49 x 243 (~430 trillion) versions. It would obviously be a challenge to actually test all of these versions. But we put a lot of effort into building an architecture that supports this type of modularity, and fortunately, it seems to be working pretty well so far. So we figured, why not, what’s another another 422 trillion permutations?

从中，我们可以看出一些线索：Gmail Labs的插件平台主要负责整合各项Labs插件对系统的改变，包括动态生成及组合影响前端界面呈现的Javascript，（可能）包括在基本处理流程的各环节中嵌入各插件的特殊处理逻辑，类似Filter Pattern。结合Google推出的开源前端框架GWT，猜想Gmail的前端界面渲染上也采取了类似GWT的“容器”+“控件推送”的机制。使得小特性的开发不需要分开完成前端和后端的设计，毕竟大部分Labs特性对前端界面的影响都在一个很有限的范围内，并以“调整”、“嵌入”等简单形式为主。

最近，Google Mobile似乎也走在了底层架构升级的浪尖。在他们官方Blog的最近多篇文章中，都显著的提到了“Iterative App”这个名词，并统一引用了下面一段话作为这个系列中每篇文章的开篇：

On April 7th, we announced a new version of Gmail for mobile for iPhone and Android-powered devices. Among the improvements was a complete redesign of the web application’s underlying code which allows us to more rapidly develop and release new features that users have been asking for, as explained in our first post. We’d like to introduce The Iterative Webapp, a series where we will continue to release features for Gmail for mobile.

看来，Gmail for Mobile也吸纳了Gmail桌面版的经验，使用了可迭代开发的底层架构。随后，我们也可以看到，Gmail for Mobile的新特性推出速度确实加快了很多。

综合上面的各种线索，我们不难得出，Google所谓的Iterative Web App，指的是一种对敏捷迭代开发有较高亲和力的软件架构。在传统的层次化、分布化、服务化、易治理的Web架构基础上，Google进一步的将项目管理的因素融入到软件架构之中，形成了一个依靠架构优势保障和推动敏捷开发的新模式，避免了迭代开发理论在项目实践中可能遇到的“空中楼阁”问题。

最后，总结一下“Iterative Web App”架构的几个典型特征：

• 高度模块化和层次化的系统设计，尽可能节省增量开发或插件化开发的重复工作量，确保迭代开发的编码环节是真正“敏捷”的。
• 高度服务化的系统布局，确保核心数据和功能独立于繁复的特性之外稳定发展。在不断推出新特性并改善现有功能的同时维持核心功能的稳定可靠。
• 灵活可控的特性容器（平台），支撑多样化的特性开发，并充分隔离各种特性间的相互影响，同时也为敏捷开发的并行性提供可能。
• 模块化测试和集成测试相结合的测试框架，保障迭代开发模块的完备性和系统的整体可用性。
• 自动化的部署系统，保障迭代开发的新特性和功能增强可以迅速可控（分阶段、可定制化……）的部署到线上。

蓝海是怎样发掘的

在Twitter这种微博客形式出现之前，博客（Blog）和即时消息群（IM.Group）是两种泾渭分明的在线交流形式。博客以博文为中心，辅以评论作为异步交流的空间；而即时消息群则强调实时性和直接交流。前者由于其过于中心化的倾向，弱化了交流的过程，而且过于依赖博文作者的写作意向；后者因其受众的相对固定性，难以充分满足个体的自我表达欲，同时也阻碍了更为广泛的交流，使得讨论主题不易凝聚。

如何才能兼顾博客“自我中心的表达”和即时消息群“及时广泛的交流氛围”，Twitter给出了答案。通过限制字数来有效降低博客的写作门槛并拓展其题材空间，鼓励更多的普通人群加入自我表达中来；另一方面，引入follow机制，吸收SNS的理念，增强了交互的广泛性和及时性。虽然最终的融合使得Twitter上的消息既没有博客看起来那么正式，也没有即时消息群那么及时和活跃，但却有效的弥补了两者的不足。满足用户最切实的需要是Twitter成功的关键。

简单和开放铸就成功

相对于大部分的SNS社群，Twitter的功能显得太过单一，就连贴图这样的基本需求也要借助第三方应用来实现。但是人们却少有抱怨，大部分用户都乐于在这种简单的形式中享受表达和交流的快乐。并不是任何简单的产品都能取得像Twitter一样的成功，如果你要买一台笔记本电脑，肯定不会选择功能单一的产品。为什么Twitter能在简单之下获得成功呢？这就是因为其彻底的开放性，将接口尽可能的开放出去，让大家来协助丰富它的功能。

Twitter的开放绝不是那种徒有其表的惺惺作态，它豪不吝惜将最直接的用户交互途径交给第三方来开发，这一点是大部分SNS网站所紧抓不放的。大部分高频度使用Twitter的用户往往都很少访问官方的Web界面，因为在几乎所有可以访问互联网的场合和设备上都能找到Twitter的第三方客户端，这使得Twitter不用支撑庞大的开发团队即可满足用户全方位的接入需要，Twitter团队将更多的精力花在与使用其API的开发者进行交流，并且不断完善这些API。

随着Twitter近年来的火爆发展，越来越多的新奇应用开始借助Twitter实现，使得用户可以轻松的在Twitter上与各类网络服务进行交互；越来越多的个人和团体开始利用Twitter宣传自己并与关注者展开交流；甚至有不少人开始用Twitter培养起Web 2.0时代的日记习惯。

共赢而不是竞争

Twitter从一开始就着力避免与主流网络服务的正面冲突，其蓝海战略为它开辟出一块避开弱肉强食的市场，其开放策略为它赢得了广泛的共生服务，其单一的功能为它争取到各大SNS社区友好合作的态度。“共赢”是Twitter一直坚持的原则，也是它坚持不把共生服务（如Twitpic）的功能引入自身的重要原因。正是这一原则，为Twitter营造出了一个友好的可持续发展的商业环境，使其能够在创业初期和上升期得以稳步发展。

不要因为它的其貌不扬而漠视它，不要因为它的功能单一而蔑视它，更不要因为它的开放接口而轻视他。正是在这一系列看似不入群的商业策略背后，潜藏着Twitter那巨大的潜力和野心。

Features:

• No client needed. Just use the built-in Email client in your phone to access most of the twitter services. (need IMAP support in the Email client, S60 confirmed)
• Public timeline / Friends timeline subscription.
• Keyword watch (Twitter search) subscription. (under implementation)
• Automatic update, without user activities. (need phone support, S60 confirmed)
• Notification for new message. (need phone support, S60 confirmed)
• Show recent messages on idle screen. (need phone support, Nokia E-series confirmed)
• Send your twitter message just like regular SMS or Email. (under implementation)
• Reply on message directly to act as @someone. (under implementation)

In Plan: (only for some operators)

• TRULY message push support. Only connect and fetch when new messages shown up, without persistent or periodic connection. Greatly save your network cost and extend the battery life.

Tweets shown on idle screen:

Write new tweet:

根据相对论的时空观，时间和空间都不是绝对的，只有真空中的光速是不变的，因此运动中参照系拥有变慢的时间和压缩的空间。但他们宣称相对论效应只有在极高速的运动中才足够明显。

今天，我要向各位揭示的是，在常规世界的广域对等分布式集群中，你可以见证不确定性原理和相对论效应的和谐共存：

• 从任何一个具有监测能力的节点上观察集群中出现的事件，它们符合不确定性原理：你无法同时准确获知事件发生的时间和位置。当事件所在节点被准确定位时，则事件发生的时间是无法精确获知的（因为脱离了单一节点，集群中便没有绝对的时间）；当试图使时间的度量有价值时（即趋近于观察者的时间），则位置将是完全不确定的（因为此时的位置相对于观察者的时空是毫无意义的）。

• 集群中两个不同节点上发生的事件在时空上是完全相对的，观察结果可能因参照系（观察者节点）的不同而不同：从独立于这两个节点的其它多个具有感知事件能力的节点上观察，则不同节点可能看到事件发生的先后次序是不同的。比如节点C可能观察到A上的事件X先于B上的事件Y发生，而另一个节点D则认为是相反的。

在广域对等分布式集群的世界中，相对论和量子力学可以完美的共存，并且相辅相成。量子力学的不确定性原理是相对论效应的前提和依据，而时空相对性则从另一个侧面佐证了不确定性原理。

最后，也是最重要的一点。从上述现象之中，我们可以学到的经验是：永远不要假定对等集群中不同节点上发生的事件具有绝对的时间先后关系！也不必费尽心思去试图同时度量集群中事件发生的精确时间和位置。

看起来，目前Google已经掌握了足够的用户特征，可以正式在其Adsense网络中推出上述针对用户特征的定向广告投放了。对我们这些互联网用户而言，也不知是福是祸…… 还是那句话，别把鸡蛋放在一个篮子里，用户隐私也是一样。

Write new tweet:

虽然不比上次Yahoo的$1.99促销时购买的oasisfeng.com这个域名，可能也不是眼下最便宜的域名注册商，但GoDaddy的服务在业界的口碑却是最大的吸引力。

BTW，域名这个东西，还是尽可能不要在国内注册，不仅价格死贵不说，要是想迁移或过户，还常被刁难。

·可以使用自己的域名或xxx.dreamhosters.com
·可以傻瓜化的架设WordPress、PhpBB、MediaWiki、Drupal、ZenPhoto等常见应用
·无缝集成Google Apps，提供邮件、办公组合等（注意：不是Google App Engine）

需要注意的几条限制：

·只能绑定从未在Dreamhost标准虚拟主机服务中绑定过的顶级域名，或xxx.dreamhosters.com，不能绑定其它二级及以上的域名
·不支持文件级管理，不能上传自己的插件、主题等
·目前阶段只能使用“邀请码”注册，有限数量的邀请码提供在这里，所以抓紧时间抢咯！

注册时的注意事项：

·别选中那些标有价格的项目，如“申请域名”，“更多主机服务”等，除非你愿意付费。

那么有一个好消息是，微软看来已经准备好解决这个问题了。但由于问题似乎是出在Live Passport那边，因此修复工作最早也要等到下个月（2009.1）。

FROM: Live Mesh Tech Preview Support <lmprev@microsoft.com>
DATE: Sat, Dec 27, 2008 at 4:06 AM
SUBJECT: 24614: DC11 – passport backend internal error – may prevent install

We are anticipating a Passport fix for this issue in the January time frame. We will follow up with you once the fix is released to make sure it worked for you. We apologize that we will not be able to take action on this issue sooner.

Thank you for this report!

Tim