金色葡萄的国内精华区

RSS是一种聚合：

RSS可以是以下三个解释的其中一个：
* Really Simple Syndication(RSS 2.0)
* RDF (Resource Description Framework) Site Summary(RSS 0.91, RSS 1.0)
* Rich Site Summary (RSS 0.9 and 1.0) 摘自维基百科

不论是syndication还是summary都含有合的意思。名字往往能够限制人们的思路。只有合，就会越合越多，直到你信息超载为止。为此有很多办法，比如digg，不过这是基于html的，比如抓虾，比如podlook。也许是出于习惯，也许是出于对作者的尊重，各种RSS频道的推荐、评分都是将一个blog的RSS作为一个整体进行的。

到此我又要吹捧一下google reader：利用Labels和share的功能，你可以把一个RSS源打散，可以给来自同一个blog的每一篇文章打上不同的标签，分别共享出你的标签，将文章按照内容、标签、甚至评价重新组合，而不是按照作者、来源。

我目前的应用是“podcast DJ”，利用Google reader，我把自己感兴趣的音频和视频播客节目分别做了两个精选。并且共享出来，初衷是给GF做一个好的播客频道，后来发现意义不仅如此。

• 这是一个人工手动分类过程，是我看过每篇文字，听过每个节目以后做出的决策

Web 2.0很大的一个特点，就是利用人的智能，叫人工智能似乎容易混淆，叫人动智能怎么样？通过联合这种人动智能，达到群体智慧的目的。

• 这个过程是一个简单的操作，不需要离开阅读界面

google reader里的星标是个很不错的功能，看到好文章只要点一下，加上星标就可以收藏了。操作简单和不离开阅读界面也许无人注意到，但是确是很厉害的。不知道有人统计过用del.cicu.os和digg的人的统计指标没有，大概是比较Geek的一伙在用。我想，每多一步操作，就会吓跑一定比例的用户。（顺便在此赞一下Palm）如果离开一个页面，就会使一部分用户流失。

通过加星标，实际上就是给某个文章投票。共享starred items share，就是把这个投票提交，如果有人订阅了这个共享星标的Feed,这次投票就算完成了。我现在订阅了5个人的共享星标Feed，感觉很好，收益良多。

如果我是Google reader，我就会把共享星标的Feed名字搞得简单些，更容易推广。让很多用户可以使用、共享、贡献。然后，由于RSS的不变性，可以从不同的共享Feed中找到同一个文章，或者反过来，看某一篇文章被多少人加了星标，被哪些人加了星标。这就是digg，用一个小小的Label就可以打倒。

更进一步，就是RSS劫持了。

困了，暂停，未完待续

未来的RSS(一)：聚合——漂浮在SP之上

几个实例：

• 我从2004年到2005年底的blog都放在了zhen.blogchina.com上，有一天突然访问不了，发信过去问，说正在查，过了几天，又发信问，说还在查。几次以后，我突然想起在google里搜索了一下，结果google挂了，于是我认识到，我终于完成了一次blogger标志性的飞跃
• 以前我在一家播客网站上申请了一个播客空间。费了好大劲，为亲友们做了一期如何订阅我的播客的节目，从如何下载iTunes，安装iTunes，到如何通过iTunes订阅Podcast Feed，要知道，这可是讲给我的父母辈的人们。在我还用skype给做过一次技术指导以后，妈妈终于会订阅我的播客了。第二天，在我上载了第一次节目以后，这个网站改版了。原来的RSS地址失效。

这两个事例，以及类似的经验使我一直对SP服务的稳定性抱有强烈的不信任。我不止一次的担心，如果我的作品被封了怎么办，我的服务商改版了怎么办，甚至我的服务商倒台了怎么办？

我首先找到的是podcast的解决方案，我使用的工具是google reader。

google reader自推出以来收到很多批评。但是，我非常欣赏它的Labels和share功能。在这里，把它作为一个Feed Burner来使用。你可以订阅不同的RSS Feed，然后用同一个label把它标记，然后共享这个label，于是就把几个RSS源合成了一个，如果其中的一个出现了问题，并不影响其他的，发布我的podcast的时候，我公布的是通过google reader共享出来的Feed。一旦需要更换服务商，只要重新订阅新的RSS，标上同样的label就可以了。

podcast可以方便的进行这个操作，因为podcast本质上是基于客户端的，用户所需要面对的繁琐操作过程只有一次，而且这样一个动作也可以被拖放或者按钮所代替。

而blog还是有所不同，大部分浏览blog，我想还是在网页上进行，特别是去发现一个新的blog的时候，还是必须要通过网页这样一个界面。

所以，未来RSS的第一个任务，就是在公开的网页上完整显示RSS源的内容。这一点Feedsky已经做到了。公开和完整是不可缺少的，比如google reader，可以完整的显示，但是它不是公开的，也就是它不是任何一个普通网页浏览者都能看到，不要注册，不要登陆，就像浏览任何一个普通页面一样浏览聚合后的页面。同样google reader也不是完整的，google reader可以把共享出的Feed，以列表的方式显示在blog上，但是这差得太远了，只不过是一个目录而已。

作为一个RSS SP或者Feed SP，理想的模式是这样的，Feed SP提供网页插件，blogger可以把合烧的Feed内容通过这个插件，显示在任何一个blog的侧边栏内。这样做，可以实现“一处更新，处处更新”。

从用户的角度解释一下，我害怕自己的blog SP出问题，也害怕自己的blog被封，那么我可以去多家blog SP申请空间，比如百度、blogbus、blogcn、MSN space，三大门户甚至blogger。申请以后，我取得各家提供的RSS，我用某个Feed合烧工具把它们聚合在一起，然后我选择一家Feed SP，输入我的blog合烧Feed，获得网页插件，然后把插件代码放置回每一个blog SP的自定义模板中，通常是侧边栏里，不过这种时候，我肯定会把侧边栏的宽度调到足够大的。于是我可以任意选择一家Blog SP作为发贴站，帖子发送以后，通过这个BSP的RSS，输送到合烧的RSS，再通过网页插件，输出到每一个blog镜像上，于是，属于我的每一个blog站点，都同步更新了。一旦其中一个收到打击，只需要转换到其他的镜像上发贴。当然Feed合烧工具是第一个弱点，一定要选择一家足够健壮的。必要的时候，可以有冗余。Feed SP是第二个弱点，但是相信一旦出现这种服务，马上会有同质竞争，只要合烧输出的Feed不变，我也只不过是换一家Feed SP而已。

这，就是所谓的漂浮于SP之上。

本文的Trackback地址是：http://www.blogbus.com/public/tb.php/2901657