Home > misc > google wave 冲击波

google wave 冲击波

June 2nd, 2009 :: jackyz

警告:本文纯属六一吹水,看客童鞋小心忽悠。

认识我有一段时间的朋友,肯定都在不同的场合分别听到过我对 “实时 Web 应用” 的鼓吹。有兴趣可以翻看去年 “CN Erlounge III” 上的《Realtime Web Application》,今年“Ajax 群英会”上的《实时 Web 应用》以及“BeijingOpenParty ——晚春夜曲”上的《实时 Web 应用中间件》。

虽说俺对于实时 Web 应用的爆发早有心理准备,但在5月31日,第一眼看到 Google Wave 的时候,还是和大家一样,被震到了。一是没有想到,实时 Web 应用还可以这么玩,太 TM 有创意了;二是没有想到,在这个“还没看清怎么玩”的领域 Google 竟然这么快就现身了,太 TM 神速了。(我很好奇,是怎样的公司文化和人才机制才能孕育这么恐怖的创新能力呢?)。

好吧,惊叹就到这里了(拍 Google 的马屁,那是众 G 粉的乐子,哪轮得着我呀)。下面照例,进入咱们的 “超强脱水” 上干货环节。

创新——Google Wave 创造性的解决了“实时”与“非实时”之间的无缝连接

非实时就是 Email ,实时就是 IM ,这两者的用户体验是如此的迥异,以至于此前试图将这两者统一起来的努力均告失败。而 Google Wave 所采用的方式则是老调重弹却又谱出新章的 Version Control —— 一个 Wave 就象是 Wiki 上的一篇文章,是一个有着版本控制的信息实体,被多个 participants (也就是用户)所共享。在这个隐喻下,非实时的访问就变成了“获取当前版本”,而实时的访问则符合“跟踪当前版本的所有更新”(所有的更新都通过实时消息广播给所有的 participants)。至此,让人目瞪口呆的 Replay 功能,也变得极其简单,只不过是版本控制的酷眩呈现而已。

现在看到很多说法,从“将会一统天下”到“未来互联网的基础应用”,等等,溢美之词不一而足。姑且认为这些都是 G 粉丝美好的 YY 吧。无须过渡诠释,咱们抛开 Google 的明星气质和强大的号召力不谈(借助这些, Google Wave 真的有成为 THE ONE 潜质也说不定)。单从“请下神坛”的“低俗化”角度, Google Wave 最本质的创新其实就是 Realtime + Wiki 并在此基础上进行各种扩充而已。有心山寨的各位山大王,从这里开始抄就对了。

技术——基于 Web 的 Realtime 技术,以及有 Google 特色的开发框架

在创新面前,任何实现层面的技术都会显得黯然失色。虽然目前还无缘得见 Google Wave 的 Realtime 实现技术,但大致可以猜出肯定是 Web Socket 或者 Ajax Long Poll 中的一种(很有可能是前者)。从技术层面而言,早已经算不上是新鲜事物了。然而有 Google 特色的开发框架(这个句式怎么听来这么耳熟呢),仍让人感到新奇。展现层的扩展直接使用了 Gadgets 模式。逻辑层的扩展则直接使用了 App Engine 的 Web 模型。

应该说,这一整套扩展方案充满了 “Google 的味道”,而且,这个模型肯定是能用的。除了 Google 系扩展一贯的稍嫌“重型”之外,唯一让人感到担心的,恐怕是这种逻辑扩展模型的抗压性。虽说使用了批量发送作为两个层次之间的阻抗匹配,但这种方法实际上仍然是将实时性更高的 Realtime 通讯构建在了实时性较低的 HTTP 通讯之上,不知道这会不会带来潜在的问题。

战略——Browser Platform/OpenSocial/OpenStand阳谋的最新尝试

Google 对 M$ 的阳谋就是 Browser Platform 战略,浏览器即平台——管你什么设备,也不关心什么 OS ,只要有一个符合 HTML5 标准的浏览器,走到哪里都是一样的用。无论是 gOS 也好,Chrome 也罢,还有 Google 对 Firefox 的大力支持,所有东西全都围绕这个核心展开。利益攸关嘛,所以,在 HTML5 上 Google 的心急和 Microsoft 的拖沓,也就显得很好理解。而这次的 Google Wave 也没有例外。以超眩的用户体验为“ HTML5 兼容浏览器”阵营奉上自己的 Killer App。民心向背是革命成败的关键,Google 的革命理论学得不错。

M$ 之外,另外一些会让 Google 这样的巨头感到巨头疼的恐怕也就只有 Facebook/Twitter 这一票跟在屁股后面猛追不舍的 SNS 了。OpenSocial 战略就是分化瓦解 SNS 集团的阳谋,但似乎不大奏效。第二梯队的 SNS 始终各怀鬼胎,最起码的 Open Platform 尚且无法贯彻,更进一步的 OpenSocial 缺乏动力也就见怪不怪了(从国内 SNS 对“开放平台”的暧昧态度就可窥见一斑)。因为无法摆平各方利益,技术相当领先的 OpenSocial 几乎快到了要沦为鸡肋的境地。而第一梯队的 Facebook 之辈用户基数则继续保持爆炸性增长,搞得 Google 很是窝心的说。如果说之前的 OpenSocial 是“跟在后面搞破坏”,那么此番祭出的 Wave 则是“抢在前面打埋伏”,而且还摆明了车马,将要彻底开源,欢迎大家山寨。用心可谓良苦,但效果目前还说不好。用户到底是会被 Network 粘得死死的,还是会被 Wave 勾得心痒痒进而纷至沓来,仍然还需要时间的检验。但,计以至此却已然到了尽头,再没有回转的余地;如若不售,后续的手段恐怕只剩下收购一条了。

OpenStand 对于 Google 来说,乃是性命之根本。试想,如果某个“封闭标准”的公司独占互联网哪怕是十分之一的内容,而且不开放内容给 Google 的爬虫(考虑一个充血版的 Facebook),那么搜索结果的质量会因此受到多大的影响?在这个普通网民都开始谈论“实时搜索”的时代,在底层(也就是通讯协议层)占据一个有利的位置(推出自己的开放标准,或者保证标准的开放性),对于 Google 这样的公司来说是一件多么重要的事?从这个角度来看,被事先高调宣布的 Google Wave 的 Open Source Product 和 Open Protocol 路线图,无论怎么看都是必须的一步棋。

Google Wave 不是实时 Web 应用的银弹

其实这是一句屁话——哪怕是在某个犄角旮旯的小不点儿领域,这个世界上也都从来就没有过什么银弹。我得承认,说“Google Wave 不是实时 Web 应用的银弹”,完完全全就是为了寻开心。一个软件老民工装出一副思想很深邃的样子,恶心一把装腔作势的软件砖家们,没办法,就是这么低级趣味。

首先,我也承认 Google Wave 眩得要命,客户方的代表看了也会喜欢得不得了,但它完完全全是基于 HTML5 标准的——你的意思是想去说服公司领导,让他们完全抛弃占据市场份额超过 80% 的广大 IE 浏览器用户么?XD,脑子笨一点不要紧,关键是不要进水就好了。

其次,我知道 Google Wave 提供了 Robots API 很多东西都可以“引入”到系统中,而利用 Gadgets API 又可以“展现”很多东西,况且 Google Wave 本身还会开源,哎呀,简直太好了,我们可以在 Google Wave 上架构我们的系统,既省钱来又省时间,这下终于有时间去泡妞了……。喂,醒一醒,XD。我们真的需要把我们的应用嵌入(接入) Google Wave 以获得 Realtime 特性,而不是相反?尤其是,当我们的应用并不像个 SNS 或者“协作系统”的时候也要如此?好吧,算你牛,非得这样,那,咱们项目组要不先回家待岗,等它出来了咱们再回来上班?

再还有,协作隐喻能够覆盖所有的 Realtime App 需求么?这是一个根本性问题,要不,咱再想想……?

干货上完,现在上水货。地址在[这里],各路水神水仙纷纷出动,精彩得紧。不要问我这水到底有多深,你自己下去探探不就知道了。;)

misc

  1. gigear
    June 5th, 2009 at 11:27 | #1

    Google Wave 将来会不会有erlang的API呢?

    想加入Erlang China 讨论组,但是好像要“会员权限的人邀请” =_=||

    另外,有个问题想请教各位,关于receive的临时保管队列,是否意味着,如果向某个进程发送无法得到匹配的东西,这些信息都会保管在临时队列里面?那这个队列会不断增大咯?

  2. jackyz
    June 5th, 2009 at 13:14 | #2

    erlang-china google groups 因为 spam 泛滥已经被迫改为邀请制的了,请留下你的 email 以便邀请。

    receive 是队列保管的,所以,你处理 receive 的代码需要小心处理,尽量按照“最佳实践”来(也就是说,确保默认有一个能匹配所有消息的规则,作为错误消息格式的处理都行),不要在这个地方“玩花样”以免出问题。

  3. gigear
    June 5th, 2009 at 13:55 | #3

    我的email是:honeygigearmax@gmail.com
    关于receive 我是否每个最后都加一个”_”进行匹配,以防止“临时保管队列”的膨胀?有没有对“保管队列”的操作呢?

  4. jackyz
    June 6th, 2009 at 20:14 | #4

    你这么做我认为没问题。

    receve
    ....
    X -> ?debug({unknown_message, X})
    end

    只要代码中存在这样的结构(最后一个模式能匹配任何消息格式),就能保证消息队列的有效清空。

    除了“加到队列”(发消息)和“队列中取出”(模式匹配),你还想对消息队列做些怎样的操作呢?如果你确实有这样的需求,我建议你应该考虑在你自己的程序内部,用 List 之类的数据结构来实现这样的需求,而不要试图让“系统级”消息队列的行为符合你的需求。

  5. gigear
    June 9th, 2009 at 14:28 | #5

    有另外一个问题,如果在一个模块中使用spawn(Fun),而Fun自身是尾递归的方式,那么,当这个模块正常退出(结束)时,那么这个Fun的线程是否仍在系统中运行?
    如果使用spawn_link(Fun),是否可以解决这个疑问呢?

    另外jackyz同学,请邀请我加入讨论组吧,我的email是:honeygigearmax@gmail.com

  6. jackyz
    June 11th, 2009 at 10:13 | #6

    cannot input chinese in google chrome for now.

    what you need is a 《Erlang 程序设计》. you will find your answers in the book.

  7. enst
    July 18th, 2009 at 08:48 | #7

    @jackyz
    你好 我想加入maillist enst.bupt@gmail.com
    没想到这里面的垃圾邮件实在是多,奇怪了,其他很火的group也没有这样啊..

  1. No trackbacks yet.