杨波·哈啰波波 ^ 点这儿

注意到Google Web Accelerator的Webmaster Help里有这样的说明：

Which links are, and aren’t, prefetchable?

Google Web Accelerator only prefetches links that should have no side effects. According to the HTTP 1.1 specification, the GET method is defined as a Safe Method which “SHOULD NOT have the significance of taking an action other than retrieval.” In practice, Google Web Accelerator does not prefetch links which have query parameters (i.e. have a “?” in the URL) and encrypted pages (i.e. URL starting with https://).

Google Web Accelerator只针对HTTP GET方式且是无参请求的页面进行了缓存，且排除了安全模式（https://）的页面。

这与Google的收录策略大致是一样的。

VoIP服务市场越来越炙手可热。在国际VoIP市场上，不仅有成功的Skype，同时，Yahoo，Microsoft，Google也跃跃欲试进入VoIP领域。并且有厂商不断的宣布进入或者准备进入这一领域。

这是理所当然的，在市场利益的驱动下，任何商家都会尽力参与其中以求分一杯羹。根据iResearch提供的整理资料显示，伴随着各国相关政策的出台，全球VoIP服务市场在未来两年将呈现高速增长趋势，甚至预计，2008年全球VoIP服务市场规模将达到210亿美元（图1）。

如此之高的市场空间，很少有商家不动心。然而，预测出来的只是一个数字，实际的效益收成，还是得依靠有效的商业模式。对目前市场上出现的VoIP产品而言，还是得依靠传统的电子商务模式，以卖点卡及自身的服务为主，同时提供相关的SP服务，以在与SP运营商分成的过程中实现VoIP的商业利润。

但是，在搜索、门户、IM及视频都相继进军广告业务的互联网发展现状下，很难想象VoIP不会对广告垂青。试想，VoIP与广告业务联姻，将是一幅什么样的场景？VoIP在客户端表现上与IM没有什么两样，然而与IM相比，VoIP倚重的并不是客户端在线人员之间的沟通。VoIP之所以能抢占IM的大面积市场，其在语音方面的表现以及用户对语音通讯的需求是关键。

假设VoIP参与广告业务，其得天独厚的音频服务是其基本的入口之一。前面大胆的设想过视频广告的传播方式，对音频广告而言，特别是VoIP来讲，有着更容易理解的方式。

试想，如果商家能够在客户使用VoIP软件拨打对方电话或者语音服务等待连接的过程中，以相关的语音广告内容来替代单调的“嘟嘟”音，在不影响客户使用服务的前提下，向用户传达友好的第三方广告信息，这是否算是VoIP对广告业务的一种尝试？当然，这只是可想到的一种非常简易广告模式。尽管如此，如果能够有商家率先实现，想必还是会给VoIP市场带来一个新的业务面貌。

有着大额市场利润前景的驱动，在VoIP的应用上出现更新更全的商业模式，是迟早的事。广告，到最终也许也只能算是其中的一个小小的业务应用罢了。

附：

图1：全球VOIP服务市场规模现状及预测

有不断的消息表明，IBM的Lotus企业级即时通讯软件Lotus Sametime与AOL、雅虎通及Gtalk即将实现互通（引用1）。这对企业应该是一个好消息，特别是对Sametime的客户（引用2）来讲，企业级IM与个人IM的互通，将会带来更为广阔的市场空间和更为广泛的市场渠道。

然而对于个人IM服务商来说，各种潜在的因素会使得互联互通不会那么容易的成行。要衡量一个个人IM的优劣，用户数是最基本也是最重要的一项参数指标。因为针对不同IM各自提供的服务亮点和用户各自不同的喜好而言，互联互通势必会造成一部分用户的均衡流失，这对拥有一定数量用户的服务商来说，是最不原意看到的。

当然，用户是希望互联互通的。互联互通意味更多的交际空间和更多的优劣选择。并且一些IM一直也在致力做到互联互通，尽管市面上还没有可用的此类服务供用户选择，不过在一些协议成了标准之后，有了服务商的支持，相应的服务应该很快就会面向用户了。

附1：基于XMPP协议对Google Talk, AIM, MSN, Yahoo Messager 实现互联工具：

Psi Jabber：http://psi-im.org/

使用方法：Connect Google Talk to AIM, MSN, & Yahoo

附2：文中相关资料引用

引用1: Lotus Sametime: IBM Instant Messaging and Web Conference。

引用2: IDC在2005年4月发布了一个企业级IM软件的市场排名：市场排名第一的是IBM的Lotus Sametime，市场占有率超过了50%；第二是SUN公司的Sun ONE Instant Messaging；第三是康维科技公司（Comverse）的ICS（Instant Communication Solution）。

目前所有的RSS客户端阅读软件都存在一个明显的弊端，即每当阅读一个Item详细信息的时候都要请求到Item服务器进行在线阅读，而不能像摘要那样脱机浏览。这对于不能联网的用户和习惯于脱机浏览的用户来讲，实在是一个无法克服的障碍。

在RSS中只输出摘要的弊端还不仅仅只在于此。由于大多Item全文不像RSS一样有固定的格式，RSS提供者以不同的输出方式提供Item，有的是网页，有的是XML，有的是纯文本，如果配合RSS匹配全文，其解析步骤也是十分麻烦的一个环节。这是在做RSS搜索引擎的时候遇到的一个棘手难题。

基于RSS的搜索引擎的数据源依赖RSS，但目前的大部分BSP及RSS提供商都没有输出全文，这势必会造成数据索引的不完整，导致数据检索的准确性和覆盖面降低。没有了全文，搜索引擎只能对Item标题和摘要建立索引，搜索范围也仅限于标题和摘要，与传统搜索引擎相比，RSS搜索引擎在命中率和数据输出上显得太过于单薄。

如此一来，一个完全的RSS搜索引擎必然的基础是RSS的全文输出。这就要求RSS提供者们能够提供一个有全文输出的RSS，而不仅仅是摘要，然而，对于RSS提供者的经营商们来说，这无疑是要了他们的命，是不可能完成的任务。对BSP及其他RSS提供者来讲，RSS是一个工具，一个非常重要的工具，这工具不是用来共享内容分享内容传播内容，而是用来增加PageView用来吸引用户用来借助更多的客户端增加页面点击数字的一种手段。

没有全文的RSS，Web仍只是停留在Page阶段。而RSS搜索引擎的开发者们也只能由每个Page入手，分析提取全文，才能为用户提供更为准确详尽的搜索结果。RSS搜索引擎与传统搜索引擎相比在精度上有更高要求的需求，而提取精准的内容，就势必要对每个Item的目标Page作出精准的解析。这对开发和带宽来讲都是一种消耗。

当然，全文输出的RSS，也会存在一些弊端。比如对一些令人讨厌的SEO们来讲就有了更多的用武之地。然而这些潜在的负面因素并不足以影响我们对RSS全文的需求。

只有当RSS全文了，分享才会简单起来。

早上浏览Donews.com的时候，看到mydonews挺好，就把mydonews.cn给注册下来了。

没想到20分钟后就被刘韧给鄙视。

决定将该域名赠送给刘韧。

注册该域名的初衷没有多想什么。没有想过做BSP，我还没有那么多资金来运营。也没有想过敲诈老大一把。donews.com是我比较敬重的站点，为我带来很多很多知识。并且donews.com也在一步步做的更好。

mydonews是个不错的标识，甚至比donews更能吸引大众，如果donews能够将这个品牌做到大众化，将更多的人聚拢到一起，那也算得上是在Mop合并Donews之后干得非常出色的一件事。

Lucene应用越来越多，在对中文对索引过程中，中文分词问题也就越来越重要。

在已有的分词模式中，目前比较常用的也是比较通用的有一元分词、二元分词和基于词库的分词三种。一元分词在Java版本上由yysun实现，并且已经收录到Apache。其实现方式比较简单，即将每一个汉字作为一个Token，例如：“这是中文字”，在经过一元分词模式分词后的结果为五个Token：这、是、中、文、字。而二元分词，则将两个相连的汉字作为一个Token划分，例如：“这是中文字”，运用二元分词模式分词后，得到的结果为：这是、是中、中文、文字。

一元分词和二元分词实现原理比较简单，基本支持所有东方语言。但二者的缺陷也比较明显。一元分词单纯的考虑了中文的文字而没有考虑到中文的词性，例如在上述的例子中，“中文”、“文字”这两个十分明显的中文词语就没有被识别出来。相反，二元分词则分出了太多的冗余的中文词，如上所述，“这是”、“是中”毫无意义的文字组合竟被划分为一个词语，而同样的缺陷，命中的词语也不十分准确，如上：在“这是中文字”中，“中文字”这个词语应该优先考虑的。而二元分词也未能实现。

基于词库的分词实现难度比较大，其模式也有多种，如微软在自己的软件中的汉语分词、海量的中文分词研究版，还有目前在.Net下实现的使用率较高的猎兔，和一些其他人自发实现的分词工具等等。其都有自己的分析体系，虽然分析精度高，但实现难度大，实现周期长，而且，对一般的中小型应用系统来讲，在精度的要求不是十分苛刻的环境下，这种模式对系统对消耗是一种奢侈行为。

在综合考虑一元分词、二元分词及基于词库的分词模式后，我大胆提出一种基于StopWord分割的分词模式。这种分词模式的设计思想是，针对要分割的段落，先由标点分割成标准的短句。然后根据设定的StopWord，将短句由StopWord最大化分割，分割为一个个词语。如：输入短句为“这是中文字”，设定的StopWord列表为：“这”、“是”，则最终的结果为：“中文字”。

这个例子相对比较简单，举个稍微长一点的例子：输入短句“中文软件需要具有对中文文本的输入、显示、编辑、输出等基本功能”，设定的StopWord列表为：“这”、“是”、“的”、“对”、“等”、“需要”、“具有”，则分割出对结果列表为：

====================
 中文软件
 中文文本
 输入
 显示
 编辑
 输出
 基本功能
====================

基本实现了想要的结果，但其中也不乏不足之处，如上述的结果中“中文软件”与“中文文本”应该分割为三个独立词“中文”、“软件”和“文本”，而不是上述的结果。

并且，对StopWord列表对设置，也是相对比较复杂的环节，没有一个确定的约束来设定StopWord。我的想法是，可以将一些无意义的主语，如“我”、“你”、“他”、“我们”、“他们”等，动词“是”、“对”、“有”等等其他各种词性诸如“的”、“啊”、“一”、“不”、“在”、“人”等等（System32目录下noise.chs文件里的内容可以作为参考）作为StopWord。

纽约时报: Google’s Shadow Payroll Is Not Such a Secret Anymore（Google 支付不存在暗箱??）。

文中提到，Google公司本部和在其他国家的Search站点对Google的贡献作用要比AdSense大，AdSense和其他地方的广告分销商为Google每赚1美元，Google则要将其中的大约78.5%返还给分销商作为登出广告的费用。

尽管这类高比例分成并不是每个分销商（AdSense的展示站点也可看作为一个分销商）都能享受到，但在一定程度上反应，AdSense作为Google推出的与AdWords并行的业务，其收益远不及AdWords。

访问http://video.google.com，不会再跳转到http://upload.video.google.com。

Video首页上有Video Store、Popular、Random三个分类。每个分类都列出了当前的Video截屏，在截屏上有一按钮，单击该按钮，可以播放该视频的缩略片断。在三个分类中，Video Store中的介绍是比较详细的，包括视频的标题、价格、日期、时间长度、来源等信息，而在其他两个分类中，只有简单的标题和时间长度。

可见，在Google的服务理念中，广告服务还是优先考虑的。在Video Store这一分类列表中，有关视频的介绍相对其他分类，其信息度就比其他两个分类更为丰富和细化。这也体现了付费就可以得到更好服务的理念。对于商家而言，商家当然希望将更多的信息送到客户面前，以让用户更深入、更直接的了解产品；同样，对于客户而言，当然也希望能获得更为丰富的信息，以判断信息的可取性与可接受程度。

不过，对于Google而言，这种传统的文字信息广告模式，在Video拥有视觉条件的前提下，应该有很大的扩展空间。试举一例，如果Google将其他商家的投放的广告，以合适的模式嵌入到视频的片头或片尾，在视频Loading的过程中，优先播放广告，如目前的Flash广告类似，在Loading的过程中，向客户传达额外的广告信息，对客户来讲，还是比较容易接受的。

此前，Google高价收购广播广告公司，且网上视频广告市场已渐成趋势，相信这种模式很快就会出现在 Video.google.com 中。

附，国内用户还无法直接享受Google Video的服务，访问http://video.google.com/videoplay?docid=-6739710473912337648，Google 提示：

Thanks for your interest in Google Video.

Currently, the playback feature of Google Video isn’t available in your country.

We hope to make this feature available more widely in the future, and we really appreciate your patience.

Google 通过官方宣布，Google Talk 将正式支持不同IM/VoIP服务之间的通讯。这一服务是建立在Google Talk的通讯协议XMPP协议基础之上的。

XMPP是目前主流的四种IM协议之一，其他三种分别为：即时信息和空间协议(IMPP)、空间和即时信息协议(PRIM)、针对即时通讯和空间平衡扩充的进程开始协议SIP(SIMPLE)。

在这四种协议中，XMPP是最灵活的。XMPP是一种基于XML的协议，它继承了在XML环境中灵活的发展性。因此，基于XMPP的应用具有超强的可扩展性。经过扩展以后的XMPP可以通过发送扩展的信息来处理用户的需求，以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程序。而且，XMPP包含了针对服务器端的软件协议，使之能与另一个进行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。

Google Talk基于XMPP，同时允许其它IM自由使用XMPP协议。如此一来，任何IM供应商在遵循XMPP协议的前提下，都可以随时与Google Talk实现免费连接。

Google Talk的这一举措将允许Google Talk用户与Earthlink、Gizmo Project、Tiscali、Netease、Chikka、MediaRing等的客户实现互通。这一服务终于由Google官方确认，可以说，XMPP协议起到了居功至伟的作用。

XMPP由Jabber软件基金会开发，最早在Jabber上实现。Jabber项目由Jeremie Miller在1998年开始的一个免费、开源的项目，用于提供给MSN、Yahoo！的IM服务。由于XMPP是一种基于XML架构的开放式协议，在IM通讯中被广泛采用，已经得到了互联网工程任务组(IETF)的批准。

但是，由于XML数据透明的缺陷，XMPP在使用的过程中，还需要努力克服它本身诸如安全方面的缺点。对于网络协同工作者而言，需要加强安全性和互连性。

附：主流的四种IM通讯协议简介

IMPP：IMPP主要定义必要的协议和数据格式，用来构建一个具有空间接收、发布能力的即时信息系统。到目前为止，这个组织已经出版了三个草案RFC，但主要的有两个：一个是针对站点空间和即时通讯模型的（RFC 2778）；另一个是针对即时通讯/空间协议需求条件的（RFC2779）。RFC2778是一个资料性质的草案，定义了所有presence和IM服务的原理。RFC2779定义了IMPP的最小需求条件。另外，这个草案还就presence服务定义了一些条款，如运行的命令、信息的格式，以及presence服务器如何把presence的状态变化通知给客户。

SIMPLE：SIMPLE是目前为止制定的较为完善的一个。SIMPLE和XMPP两个协议，都符合RFC2778和RFC2779 。SIMPLE计划利用SIP来发送presence信息。SIP是IETF中为终端制定的协议。SIP一般考虑用在建立语音通话中，一旦连接以后，依靠如实时协议（RTP）来进行实际上的语音发送。但SIP不仅仅能被用在语音中，也可以用于视频。SIMPLE被定义为建立一个IM进程的方法。SIMPLE在2002年夏季得到额外的信任，目前，微软和IBM都致力于在它们的即时通讯系统中实现这个协议。 SIMPLE小组致力于进程模式的操作，这将提升运行效率，使基于SIP的机制能够进行会议和三方电话交谈控制，也考虑到能和未来提供的许多新特性实现兼容并提升表现能力。有了进程模式，SIMPLE使用SIP来建立一次进程，再利用SDP（进程描述协议)来实际传输IM数据。

PRIM：PRIM与XMPP、 SIMPLE类似，但已经不再使用了。

（本文部分数据来源于互联网）

Slashdot上消息，Google在微软宣布进入在线广告市场之后，随即同广播广告公司dMarc达成协议，以12.4亿美元高价收购该公司。

该举动表明Google的广告市场策略在未来两三年内将会发生较大的变化，由目前单纯的依赖互联网网络广告向其他媒体扩展。尽管目前还不知道Google会如何利用广播这一媒体，但起码上，Google向其他媒体扩展转型的决心，就足以搅动整个广告市场。

另外，根据iResearch整理的资料显示，在美国，网上视频广告市场已渐成趋势，不知道Google此次的收购动作是否暗示了其也将进军视频广告的野心。

附：美国网上视频广告发展趋势图

对于一般的海量型搜索引擎，大多由机器人在一定时间内循环抓取内容源，这势必会造成重复访问部分页面。其重复的频度一般由搜索引擎自己决定，但大多是根据网页的优先级来考虑。如果被访的网站本身不是很热门，其对应的页面调度时间周期也就相应会延长，在短时间内被搜索引擎访问的几率也就相对较低。然而对于时事性要求比较高的搜索引擎，比如垂直型搜索引擎，一般具有固定的内容源地址，其抓取的频度就依赖于源网页的更新频度。这个时候，如果源网页输出没有做到尽可能的输出优化，就会给自己的网站带来不必要的压力负担。

车东分析了FeedBunner的抓取日志，FeedBurner的更新频度: 30分钟同步一次，可以看出，在搜索引擎高频率的请求中，搜索引擎并没有请求真正的实体，而是在成功的发送了GET请求后，优先得到服务器的返回代码，根据返回代码来判断实体文件是否有更新，如果有更新则获取真正的实体内容。

在服务器返回的代码中，如果目标未更新则返回 304 “Not Modified”。

304是对应文件自If-Modified-Since域所指定的日期以来就没有更新过，服务器应当回应此状态码，而不是将实体主体发送给客户端。回应标题域中只应包括一些相关信息，比如缓存管理器、与实体最近更新（entity’s Last-Modified）日期无关的修改。相关标题域的例子有：日期、服务器、过期时间。每当304回应中给出的域值发生变化，缓存都应当对缓存的实体进行更新。

304一般是根据实体（目标页面）的最后更新时间来确定，对于动态页面，Last Modified 一般会取系统当前时间值，服务器不会返回304。如果搜索引擎抓取的目标是动态页面，则每次都会请求实体，将会对系统带来额外的压力。

为了配合搜索引擎，将页面静态化，是个不错的策略。

“Write Post” or “Write Page”?

This’s “Write Post” Action!

“Write Post”: 文章可以在Post Status里选择Published，则会发表在Blog上；

“Write Page”: 文章没有Post Status选项，只能保存在站内，而不能公开。