2008年5月10日

有备无患:绕过 GHS 用自定义域名发布 Blogger

2007年1月,Google Blogger 的自定义域名功能推出不到一个星期,就被 GFW 给废了。原因就是 GFW 隔断了国内用户对 Google 的免费主机托管服务 ghs.google.com 的访问。

今天试着将 App Engine 应用部署到自己域名的时候,发现 App Engine 不需要将 CNAME record 指向 ghs.google.com,从而可以避开 GFW。而同样的方法也可以适用于 Blogger。方法如下:

  1. 把 Blogger 的发布方式切换成“自定义域名(Custom Domain)”。在“你的域名(Your Domain)”一栏中填上域名,比如,py.thonic.org。保存设置(Save Settings)。
  2. 在你的域名注册商那里,修改域名(thonic.org)的 DNS 设置。为子域名(py)添加一条 A record,指向下面四个 IP 地址的其中之一。举例来说,就是添加这样一条记录:py.thonic.org 86400 IN A 216.239.34.21
    • 216.239.32.21
    • 216.239.34.21
    • 216.239.36.21
    • 216.239.38.21

DNS 设置的改动需要一段时间来完成,一般不会超过24小时。这样就可以重新使用 Blogger 的自定义域名功能了,只是,这次又可以持续多久呢?

2008-06-26 UPDATE

我把上面的 IP 绑定到自己的域名了,ghs.luliban.com。以后也可以像 ghs.google.com 一样,添加一条 CNAME 记录到 ghs.luliban.com 来绑定 Google Blogger 或者 Google Apps 了。

标签: ,

2008年5月9日

有备无患:在 Google App Engine上应用豆瓣 API 的授权认证

上次说到了在 App Engine 上应用的豆瓣的 Python 客户端,但是那个版本(0.1.1)的客户端并没有包括 OAuth 授权认证的功能。如果想要让用户授权,以访问那些受保护的资源,以及添加、修改或删除用户的收藏,需要从豆瓣 Python 客户端的 SVN 中获取最新的开发版本(r22)。据豆瓣的开发人员 hongqn 说,OAuth Client 基本开发完毕,已经进入内测 bug 的阶段。

和 GData Python 客户端一样,开发版本的 OAuth Client 也是用 Python 自带的 httplib 模块来处理 HTTP 请求,所以原始的客户端不能直接在 App Engine 上使用,必须先将 httplib 替换成 urlfetch。现在只需要修改两个函数,但是豆瓣如果能像 GData Python 客户端一样把使用 httplib 的部分封装起来,甚至提供一个使用 urlfetch 的替换模块就更好了,希望豆瓣能采纳这个建议。下面是具体步骤,如果有什么问题,还请留言告知。

1,从 trunk 中 checkout 最新的豆瓣 Python 客户端开发版本
$ svn co http://douban-python.googlecode.com/svn/trunk/ douban-python/

2,修改客户端的 OAuth Client
$ cp douban-python/douban ~/doupye/douban -rf
$ cd ~/doupye/douban/
$ gvim client.py

client.py

# import httplib
from google.appengine.api import urlfetch

class OAuthClient:
    ... ...
    def fetch_token(self, oauth_request):
        # 被注释掉的是原来使用 httplib 的部分
        # connection = httplib.HTTPConnection("%s:%d" % (self.server, 80))
        # connection.request('GET', oauth_request.http_url,
        #     headers=oauth_request.to_header())
        # response = connection.getresponse()
        # r = response.read()
        url = oauth_request.http_url
        result = urlfetch.fetch(url, headers=oauth_request.to_header())
        r = result.content
        ... ...

    def access_resource(self, method, url, body=None):
        ... ...
        # connection = httplib.HTTPConnection("%s:%d" % (self.server, 80))
        # connection.request(method, url, body=body,
        #     headers=headers)
        # return connection.getresponse()
        result = urlfetch.fetch(url, payload=body, method=method, headers=headers)
        return result.content

3,使用 OAuth 授权的过程如下,在 App Engine SDK 提供的控制台(Interactive Console)中运行:
from douban.client import OAuthClient

client = OAuthClient(key=MY_API_KEY, secret=MY_SECRET)

# 获取未授权的Request Token
key, secret = client.get_request_token()
print key, secret
>>> c14023315549fe3743c17993ff4dfaa5 91af6245103ec3b7

# 获取请求用户授权的页面的 URL
url = client.get_authorization_url(key, secret)
print url
>>> http://www.douban.com/service/auth/authorize?oauth_token=a9e487ac36e0ba9efdba970534a22fce

# 将 URL 复制到浏览器中,用户可以选择同意或者拒绝授权

# 用户完成授权后,使用授权后的 Request Token 换取 Access Token
key, secret = client.get_access_token(key, secret)
if key:
    # 使用 Access Token 登录
    login = client.login(key, secret)
    print login
>>> True

# 访问受保护资源
collections = client.access_resource(method='GET',
    url='http://api.douban.com/people/wyt/collection?cat=book')
for entry in collections.entry:
    print entry.title.text
>>>
听过 人として軸がぶれている
想读 Antipatterns
想读 新企业的起源与演进
看过 .hack//G.U. Trilogy
想听 ワイルドストロベリー
在听 The Flower Book
在听 E=MC²
听过 越长大越孤单
想读 Investing 101
想读 The Ecology of Commerce

标签: , ,

2008年4月21日

有备无患:在 Google App Engine 上应用豆瓣 Python 客户端

Google App Engine 是 Google 四月初推出的一个网络应用开发平台,它提供了一体化的分布式服务器群、供快速开发的网络应用开发框架、最多500MB的数据存储,以及可自动升级的后台流量统计服务。换言之,App Engine 让开发人员专注于应用本身,Google 将提供应用运行及维护所需要的一切平台资源。

App Engine 目前只支持 Python 作为唯一的开发语言(wyt:谁让“Python 之父” Guido van Rossum 也在 Google 工作呢,近水楼台先得月)。所以,如果想在 App Engine 上利用豆瓣开放的书影音和用户数据,我们可以使用豆瓣提供的 Python 客户端来开发。另外,由于以前的 GData Python 客户端 都是用 httplib 模块来处理 HTTP 请求,而 App Engine 则规定必须通过其自带的 urlfetch 才能实现,所以为了让豆瓣 Python 客户端所必须的 gdata.service 模块能够正常的在 App Engine 上工作,我们还需要版本号大于1.0.12.1的 gdata-python-client。下面是具体步骤,如果有什么问题,还请留言告知。

1,下载 gdata.py-1.0.12.1.tar.gz
2,解压缩到当前目录,并编译 gdata

$ tar xf gdata.py-1.0.12.1.tar.gz
$ cd gdata.py-1.0.12.1/
$ ./setup.py build

3,将编译好的 atom 和 gdata 目录复制到项目目录 ~/doupye/

$ cp build/lib/* ~/doupye/

4,下载 douban-python-0.1.1.tar.gz
5,解压缩到当前目录,并编译 douban-python

$ cd ..
$ tar xf douban-python-0.1.1.tar.gz
$ cd douban-python-0.1.1/
$ ./setup.py build

6,将编译好的 douban 目录复制到项目目录 ~/doupye/

$ cp build/lib/* ~/doupye/

7,修改豆瓣的 Python 客户端文件 service.py

$ cd ~/doupye/douban/
$ gvim service.py

service.py

import gdata.service
# 添加下面两行,让所有的 HTTP 请求调用 App Engine 的 urlfetch (?)
import gdata.urlfetch
gdata.service.http_request_handler = gdata.urlfetch


演示网页

http://doupye.appspot.com/demo/douban_python_client/

标签: , ,

2008年4月9日

有备无患:用 AideRSS + Google Reader 辅助阅读

前几天我计算出自己的 FRER(Feed 阅读效率评价)为15.14,这意味着在 Google Reader 读到的大约85%的文章,至少对我来说,是噪声。这里所浪费的时间,虽然不能直接推算,但估计至少有三分之一。为了更有效率的利用这些时间,我尝试用 AideRSS 为 Google Reader 设计的 Firefox 扩展来辅助阅读。

AideRSS 原本是一款在线的 feed 过滤工具。它通过分析 PageRank,文章评论和 Trackback 的数量,以及文章被 del.icio.us 和 Digg 用户收藏的次数等指标,计算出相应的 AideRSS PostRank(从1.0到10),并以此为用户过滤 feeds 减少信息过载带来的困扰。而 AideRSS 的这个 Firefox 扩展将 PostRank 整合到 Google Reader 中,我们可以在每一篇文章的标题左侧看到相应的 PostRank,在末尾看到相应的评论、Trackback、del.icio.us 和 digg 收藏的具体数目。另外,我们还可根据 PostRank 的高低过滤出 Good,Great 和 Best 的文章来选择阅读。



几天使用下来,AideRSS 确实能提高一些阅读的命中率,特别是在读流量大更新快的 blogs 的时候,比如CrunchGear,LifeHacker 等。另外读那些只输出摘要的 feeds 的时候,比如新闻类的 feeds,del.icio.us 上的 linux tag 等,我也可以根据 PostRank 快速过滤掉一些文章。

另一方面,AideRSS 对草根 blogs 不会像豆瓣九点那么“势利眼”——死盯着订阅数不放,不用去担心 PostRank 会不会把草根的声音屏蔽了的问题。PostRank 的算法中,似乎流量较少的草根们反而更“容易”拿到高 PostRank。举例子来说,我的《有备无患:为Blogger传统模板(FTP发布)添加标签云》只有4个 backlink,2条评论和2个 del.icio.us 收藏,被评到8.3分,而 LifeHacker 的《Bind Papers Together Without Staples or Clips [How To]》有39条评论,7次 del.icio.us,5次 digg,却只有5.3分。

虽然 AideRSS + Google Reader Firefox Extension 还在 private beta 阶段,虽然会拖慢 Google Reader 的响应速度(wyt:要通过 AideRSS 的服务器取数据),虽然还和 Firefox 上最流行的扩展之一 GreaseMonkey 有冲突(wyt:AideRSS 另外提供了一个 GM 脚本,实现和扩展同样的功能),它还是值得去试一试。不过,真正的结论还要等几个星期以后,看看我的 FRER 有没有因此而提高了。

标签: , ,

2007年1月5日

南言北哲:助纣为虐,Google向迅雷投资500万美元

这或许是一笔不错的买卖,对双方来说。

迅雷将从Google获取更多的网页索引,和更优秀的搜索引擎技术的支持。而Google将获得更多来自中国的流量,来拯救2006年不断下滑的市场份额。就像全球范围内Yahoo和eBay的“反Google联盟”一样,一年多的时间足够让Google意识到一个强大的中国盟友的必要性,尤其是面对着在中国市场上看起来异常强大的百度。

但是,迅雷就是答案么?

迅雷在初期推广阶段,就像其他急欲占据用户桌面的流氓软件一样,捆绑插件,强制安装,留后门,无所不用其极,是标准的“流氓软件”。虽然在成功扩张用户群之后得以漂白,“令人遗憾”的没有赶上去年反流氓软件的大潮,但是互联网并没有那么健忘,Google一下“迅雷 流氓软件”就可以得到722,000个网页。

去年10月,当Google用16.5亿美元的股票收购YouTube的时候,不少分析家就认为YouTube的版权问题将会为Google惹来不少麻烦。但是随着Google的股票节节高升,YouTube和唱片公司达成合作协议,人们逐渐开始相信YouTube有解决版权问题的能力,毕竟YouTube是一家以共享个人创意视频为初衷的网站。可是,如果让迅雷把侵权的mp3,盗版的电影和破解版的商业软件剔除出搜索的结果之后,还能剩下些多少资源,还能剩下多少用户呢?和YouTube不一样,迅雷的生存手段就是赤裸裸的侵权和违法,即便是Google也改变不了这一点。

携手流氓软件侵犯版权,也许Google还坚守“不作恶”这条座右铭,但是“不助纣为虐”也许并不在Google的保证之内。

迅雷之所以获得1.1亿全球用户,除了“流氓营销”之外,下载速度快是很重要的原因。迅雷在下载的过程中,会自动搜索其他网站上的类似网页,盗取其下载链接作为镜像,加快迅雷用户的下载速度。这种“强盗式”的下载,除了增加被盗链网站的服务器负载和带宽成本之外,更糟糕的是间接阻止了用户访问这些提供下载的网站,减少了这些网站的流量以及由流量而产生的经济效益,从而威胁到了这些网站生存的根本。所以才会有去年6月华军天空联手封杀迅雷的事件。

而现在Google的加入,让情况更加微妙起来。迅雷得到Google的技术支持后,可以更多更准确的找到下载链接,也就是下载网站的页面访问流量会更少。而这些网站中不乏Adsense的忠实用户,他们为Google带来Adwards的点击收入,可是Google却在让他们蒙受损失;另一方面,随着流量的减少,Google Adwards客户们,也在错失一个又一个赚钱的机会,而Google也无法从广告点击中获益。这些对Google来说或许都不是大数目,但是对他的用户来说却不会是一笔小数目。

Marks Cuban有一句话很酷,


It's always business. It's always personal. All good businesses are personal. The best businesses are very personal.(生意就是人情,越是出色的生意人情味越浓。)


这不是一笔出色的生意,对于Google的用户来说。

标签: , ,

2006年10月24日

南言北哲:16.5亿美元,Google收购YouTube

Google收购YouTube,花了16.5亿美元的Google股票。

YouTube来说,这是个令人眼红的价格。创始人Steve Chen(27岁)和Chad Hurley(29岁)一夜间变身亿万富翁,而红杉,YouTube的主要投资者则收获了4亿多美元。

Google来说,这是个令人嘴馋的市场。Google的股价自从完成收购后,已经从420美元飙升到了令人咋舌的484美元(10月23日),而相比之下Yahoo!和Microsoft的股价就惨淡许多了。

或许互联网的视频时代已经来临了。类似YouTube这样的网络视频服务正在改变人们的收看电视的习惯,毫无疑问的,就像门户网站曾经改变了人们阅读报纸的习惯一样。人们将从一堆没有品位没有热情没有创意的“三无”电视节目中解放出来,或者在YouTube上分享自己的聚会小短片,和朋友们一起喜怒哀乐;或者看看另类的搞笑小节目;当然最受欢迎的还是狠狠地恶搞《夜宴》《无极》这些无聊电影,“化废为宝”。

有眼球的地方就有广告的价值,在线视频可能是下一个百亿美元的广告市场。而同时拥有庞大的广告来源(YouTube)和完善的广告投放机制(Google Adwards)的 Google,在竞争中几乎占尽了先机,难怪默多克会不爽了。但说实话,比起自大的传媒巨头来,Google的座右铭“Don't Be Evil”似乎来得更可靠一些,至少我们还能记得Google坚持不投放横幅广告和坚持不采用竞价排名来扰乱搜索结果的做法。

对Google,我们可以有更多的期待。

Google的目标是“帮助人们找到所需要的任何东西。”那么对于视频来说,怎么样才能找到符合条件的视频文件呢?仅仅提供作者信息,当然是不够的;而类似YouTube的利用TAG标签来分类的方式,让我们仿佛回到了《杨致远和大卫·费罗的万维网指南》的时代,一个完全主观的标签集合。这大概是主张机器搜索的Google难以忍受的。何况,网页搜索引擎是从实现了全文搜索之后,才真正改变了人类寻找信息的方式。那么对于视频来说,实现全视频搜索是不是一件可以值得期待的事情呢?

标签: ,

2006年10月11日

悠言悠闲:Wiki解封了,GOffice成型了,教育网还不能访问YouTube?

  1. 晚上回来发现Wiki解封了。更准确的说法是,GFW升级了。有敏感单词,比如“六四”,的页面还是不能访问,但其他正常。聊胜于无。
  2. Google把WritelySpreadsheets整合在一起,重新命名为Google Docs & Speadsheets,界面也是Google Style。Google Office离我们不远了。
  3. Google用16.5亿美元收购了YouTube。希望李开复不要忘记通知一下CERNET,国内公务员的无知和低效我们很都清楚。到底什么时候教育网能直接访问YouTube啊?

标签: ,

2006年9月15日

悠言悠闲:今天让Live Messenger退休了

Live Messenger是越来越胖了。无论是越来越长的左侧选项卡,越来越多的捆绑插件,还是越来越大的安装文件,都大有赶超QQ的趋势。我喜欢的是简单而精致的东西,比如Google Talk

Gtalk支持标准Jabber/XMPP协议,可以通过其它协议访问网络。所以MSN、QQ、Yahoo!等采用封闭协议的IM,理论上Gtalk都可以实现互联。不过我们仍然需要一个第三方软件,比如Psi,来帮助Gtalk导入Live Messenger的好友名单。

Psi是一个优秀的Jabber客户端,而且绿色免费有丰富的帮助文档直接下载zip文件/访问镜像下载页面),赞一个。

安装完成后,首先要用Gmail账户登陆Psi。在Gtalk的帮 助页面上有详细的配置说明,这里简单重复一下。第一次打开Psi后,需要添加账户。接着进入Psi:Account Properties(账户属性)对话框,Jabber ID:输入Gmail地址例如user@gmail.com,Password:Gmail密码。然后打开Connection选项卡,选中Manually specify server host/port,Host:输入talk.google.com,port:5223。保存后,就可以用Gmail账户登陆Psi 了。

然后把Live Messenger的好友列表导入Psi中。打开Psi:Service Discovery(服务探索),Address:输入ursine.ca,点击Browse(浏览)。右 键单击MSN Transport (ursine.ca users only)一项,点击Register(注册)。出现Registration:msn.ursine.ca对话框,Username:输入 Live账号例如user@hotmail.com,Password:Live密码,点击Register。这样Psi就会导入Live Messenger的联系人列表了。

最后需要整理一下Gmail contacts。导入的Live Messenger联系人格式为user%hotmail.com@msn.ursine.ca,user是Live账户的名字,hotmail.com 是Live账户使用的邮箱类型,而msn.ursine.ca是Gmail和Live Messenger相互通信的服务器名。以后添加Live用户也是一样的格式,比如要添加我的话,用户名是ghostage@hotmail.com,在 Gtalk中就是ghostage%hotmail.com@msn.ursine.ca。还有需要注意的是,刚刚导入的联系人是没有姓名和其他信息的, 需要到Gmail Contacts一个一个重新添加。

这样子就完成了让Live Messenger退休的工作,平时只要打开Gtalk就可以同时看到Live和Gtalk上的朋友了。

标签: ,

2006年8月2日

悠言悠闲:FeedBurner访问恢复,MSN Space升级,Blogspot解封?

FeedBurner:实习回来发现FeedBurner恢复访问了。谢天谢地之余,犹有后怕,这究竟是有些人把建军节当作愚人节了呢,还是。。。Anyway,既然MSN Space不能通过修改rss/feed,来强壮自己的FeedBurner rss/feed,那只有注册一个FeedSky帐号以备不时之需。

Live Space:跳票了半个多月的Live Spaces,终于在美国时间的“中国建军节”进行了升级。到目前为止,还有些Spaces不能访问,看起来升级还在进行中。新升级的Live Spaces界面更加简洁,更多的应用了AJAX技术,同时也添加了许多web2.0设计风格的元素。升级通常都是很不错的事情,但是同时也有一些麻烦事。

第一,字体的显示有些不正常。在ie里面,英语字体的高度明显比中文字体低了许多(像是“谷歌Google”),但是在Firefox上显示倒是没有这个问题——难道Microsoft出了内奸?

第二,Spaces的域名又改了。这次变成了user.spaces.live.com,虽然以前的域名仍旧能够重新定向到Live Spaces,但是更新一下blog roll还是免不了的。

第三,因为域名改了,Bloglines和其他一些rss阅读器会把这些新域名上的旧内容判定为新内容。于是成千上万的旧文章又重新冒了出来,实在是一件非常非常麻烦的事情。

Blogspot:听说Blogspot解封了,我也试了试,不过没什么用。不过Firefox上显示的不是被reset了,而是和昨天FeedBurner相似的,

The server at googleblog.blogspot.com is taking too long to respond.

难道有盼头?BTW我用的是上海电信有线通。

标签: , ,

2006年7月29日

悠言悠闲:Gtalk 发布了些新功能

Google Talk 发布了一些新功能,包括传输文件,发送语音邮件显示正在听的音乐

文件传输:旧版本的 Google Talk 不支持文件传输,想要共享文件的话只有通过 Gmail 发送 email 附件。当然 Gmail 也很方便,同 Gtalk 的关系也异常亲密,不过直接传输文件操作起来显然更加简单了。当传输文件的时候,文件的图标会一同显示。而当你传输照片的时候,显示的就是照片的缩略图了。

语音留言:通过 Google Talk 即时发送,而你的朋友就会在邮箱里收到一封有音频文件作为附件的 email。

音乐状态:能显示现在正在听的音乐,和我们在 Windows Live Messenger 里看到一的样。只是 Google Talk 支持的播放器更多,目前包括 iTunes、Windows Media Player、Yahoo Music Engine 和大名鼎鼎的 Winamp。可是我唯一在用的 foobar 不在上面。哭~

标签:

2006年7月26日

南言北哲:当 Google Office 遇上搜索

Google 是长尾的典型案例。Google AdSense 将无数小企业小客户的广告需求,聚合成一个超巨大的长尾广告市场,大到 AdSense 在今年第二季度的收益达到9.97亿美元,比去年同期增长了58%。而这也只是 Google 第二季度总收入的40%,剩下的60%收入即14.3亿美元来自于 Google 的另一条"长尾巴"—— 超长的产品线。而在这条产品线上,有些单词组合在一起是最吸引人的,比如 Gmail WritelyCalendar Page Creator Spreadsheets。人们都怎么说来着。

Google Office的轮廓渐渐清晰起来。但是 Google 真的要做 office 吗?诚然像keso说的,相比于传统的 office 来,Google 的 web office 有着这样些优势。


  • 在线服务。软件作为服务,而非盒装产品,无需安装,无装机量限制,无版本升级限制。
  • 共享。可与他人实时地分享并共同编辑同一文档,而不是作为电子邮件的附件发送。
  • 免费。一套Microsoft Office标准版要卖300美元,一套专业版要卖500美元。

但 Google Office 作为网络服务也有自身先天的缺点,比如速度慢安全性弱和功能简单等问题。虽然可能有些人对这些问题无所谓,比如我^^,但不会包括企业级用户。企业级用户的需求是速度快安全性高,超容易上手但也能够实现复杂的功能。而网络共享并不是必须的,因为文件可以通过局域网传输。当然没有人不喜欢免费的东西。但是免费又有保障的东西有多少呢。他们希望每次版本变更仅是原有基础上的 improvement,就像 Microsoft Office 所做的;而 Google 的升级风格向来是 revolution,我想这是个褒义词,但对于企业级用户来说,可能真的会吓到他们。

Microsoft 的 Dare Obasanjo 就认为,Google搜索结果的相关性正在变坏,但 Google 却把他们的资源和注意力大量地浪费在不相干的地方。Obasanjo 说,Google 要做 office,Microsoft 笑了。可是 Google 能让 Microsoft 笑么?不能。所以 Google 不会做 office。
那 Google 在干嘛呢。Microsoft Chief Operating Officer Kevin Turner 说, "企业搜索(Enterprise Search)是我们的生意,这里是我们的地盘,Google 最好别想在这里捞到好处。。。那些家伙永远别指望从我们的碗里夹菜吃,即使看起来他们想那么做。" -___-
且不理会 Turner 的自信是从哪里来的,也不管他是不是也用 Google 搜索过"欧盟到底罚了微软多少钱",但至少可以看出来,对 Microsoft 来说,Google 最大的威胁仍旧来自于他们的搜索引擎技术。

搜索引擎就是信息整合的过程。没有信息,搜索引擎本身不能创造任何价值。但反过来说,只要有大量信息,搜索引擎就有其存在的价值,因为经过整合的信息的价值比其原始价值大得许多。

那么,当 Google Office 和搜索引擎结合在一起的时候,又会让我们想到什么呢?Microsoft 想到了企业搜索,因为他们一直做这个。而我则想起了文件搜索(File Search),因为 Google 的产品线上还有一款非常有特色的产品, Google Desktop

Desktop 的基本功能是建立一个文件的索引,以便快速搜索计算机,查找电子邮件、网络历史记录及文件。如果把互联网上的计算机上的 Desktop 连接起来,把它们的索引进行共享,那么我们就可以轻松的实现互联网范围内的文件搜索了。当然这种粗暴的做法会侵犯隐私权和版权,所以这只是个通俗易懂的假设。我们不妨换一个思路——如果我们在 Google 的服务器上存储了一些没有法律问题的可以被公开的文件,并建立一个可以从互联网进行访问的 Desktop 索引,那我们也同样的可以搜索文件了。

还有一个问题,由谁来贡献文件呢。不要指望 Google 去做华军或者天空,Google 会让用户来贡献内容,通过 Google Office。

终于话题扯回到了 Google Office。现在我们可能有点明白 Google 为什么开发 Office 系列服务了——为文件搜索服务,提供一个可以让用户自主的创作和共享文件的平台。也就是说,当我们用 Wirtely 码字,用 Spreadsheets 做报表,用 Calendar 记录日程安排,并且把这些内容被贴上 public 标签的时候,就意味着这些文件被纳入被搜索(Search Enabled)的范围内了,而我们也可以在 Google 的文件搜索服务中搜索出其他人贡献的文件。

最近,Google 加入了开放文档联盟(ODF Alliance),也说明 Google Office 以后会更文件化,而不只是以网页的形式存储信息。毕竟搜索到需要的内容,却发现只支持网页和 Microsoft Office,谁都会很郁闷的吧。^^

标签: ,