« February 2004 | Main | April 2004 »
March 27, 2004
给所有想从事软件研发的年轻工程师的忠告与建议
[url=http://www.blogchina.com/new/display/26823.html]http://www.blogchina.com/new/display/26823.html[/url]
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
March 25, 2004
分析：RSS带来“个性化搜索”
[url=http://www.blogchina.com/new/display/26494.html]http://www.blogchina.com/new/display/26494.html[/url]
分析：RSS带来“个性化搜索”
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
March 23, 2004
上Poco，免费做爱做的事！
上Poco，免费做爱做的事！
数码，摄影，美食，音乐，mp3，电影下载，动漫，社区，交友，写真，免费下载，个人主页
[url=http://www.poco.cn/]http://www.poco.cn/[/url]
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
March 22, 2004
一个天气预报站点
[url=http://www.wunderground.com/]http://www.wunderground.com/[/url]
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
IM协议的开放
在Internet上协议的开放才真正的让它发展到现在这步田地。但是不知为什么，在现在的Internet上，封闭的协议却更多的放在大家嘴边，看看国人著名的腾讯，看看新时代的3721。而许久以前的MS的MSN与AOL的AIM/ICQ协议之争也让大家感觉封闭带来的不爽的感觉。我这两天仔细的看了看，把用户较多的几个IM的协议和第三方Lib找了找，发现，国外的技术也不想我们想的哪么封闭，大家最终还是要走向开放，不知国人什么时候也能走到这一步。
MORE...
先来看看MSN，令我想不到的是MSN有一个专门的网站用以说明了MSN的各种协议。而且有不少人以其文档做为参考开发了相关的Lib
Java：TjMSN、jmsn
Python：msnp.py、pebrot
近些年我用ICQ的次数越来越少了，虽然我使用ICQ最早，但是现在越来越难登录到ICQ上了。但是我想使用ICQ的用户不会在少数的。这里有ICQ各个版本协议的说明。而相关的Lib相比msn少了不少。
Java： Instant Messenger Lib (ICQ/AIM)、jcq2k ICQ v7 protocol Java library
Python：py-icq
找Yahoo message的协议真是不好找，但是还是FreeBSD提供了一个好的路径，在它的ports中有一个叫做libyahoo2的，让我们找到了一个新的天地。在它的站点中提供了Yahoo Message的Protocol Docs。
Java：YMSG Java API
当然，也有不少人要大而全，他们在同一个包中打入了多种IM的支持，一般包括MSN、AIM、ICQ、Yahoo、Jabber。
Java：PlanetaMessenger.org、Echomine Muse Communications API 、
Hamsam
更有人使用IM的协议做了一些有意思的事，这是一个使用MSN协议进行远程控制的软件叫做MS Shell。
不知在IM的世界中还会发生什么事。 :)
不过，这些所谓的开放其实也是很封闭的，唯一开放的原因是真的有不少人让这些协议开放了出来，我想国人的一系列的IM也会有这么一天的。我们等等罢
原文：
[url=http://blog.huangdong.com/comments.php?id=33_0_1_0_C]http://blog.huangdong.com/comments.php?id=33_0_1_0_C[/url]
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
MSN Messenger 编程
[url=http://www.msner.com/bbs/list.asp?boardid=13&page=1]http://www.msner.com/bbs/list.asp?boardid=13&page=1[/url]
ivanchen
axmanchen
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
March 21, 2004
PKM工具推荐
Internet资源 MyIE2 [url=http://www.myie2.com/]http://www.myie2.com/[/url]
MyIE2 的特色功能介绍
多页面浏览界面
鼠标手势
超级拖放
隐私保护
广告猎手
快速网络服务
Google 工具栏支持
外部工具栏
收藏工具栏
皮肤支持
人际资源 IncrediMail [url=http://www.incredimail.com]http://www.incredimail.com[/url]
IncrediMail 是一个与众不同的E-mail软件。它具有非常酷的视窗介面、寄信动画效果、可爱的收件信差。还有很多的信签、动画、音效、卡片等，可以组合成出非常炫的电子邮件。让写E-mail和看E-mail都变成新鲜的体验。
这个软件不仅界面超炫，而且功能强大又人性化。
用它可以管理YAHOO、HOTMAIL等各种非POP的邮件帐户，通过Message Rule功能可以轻松实现中国人比较习惯的多帐户方式。还可以根据不同的帐户显示不同的通知图标，比手机的来显示还要方便。对于普通EMAIL管理软件的阻止发件人，在服务器端预览邮件等功能更是不在话呀。实在值得体验一下！
文档资源 Mybase [url=http://www.wjjsoft.com/]http://www.wjjsoft.com/[/url]
Mybase 是一个功能强大且可随心所欲自定义格式及层次关系的通用资料管理软件， 可用于管理各种各样的信息，如：各类文档、文件、资料、名片、事件、日记、项目、笔记、下载的精华、收集的各种资料等等，即使毫无规律的资料，经过精心组织后，也一样可以管理得有条不紊。
Mybase 用途比较广泛，通常可以被用作：日记本、记事本、通讯录、相片簿、文档索引、电子书籍、学生笔记、教师备课、工作计划、学习研究备注、项目管理、知识库管理、客户资料管理等等。总之，其数据组织能力足够灵活，允许您自定义更多的适合具体情况的各种用途。
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
TrackBack技术规范
TrackBack技术规范
出自：http://hedong.3322.org/archives/000351.html
原文是[url=http://www.movabletype.org/docs/mttrackback.html]TrackBack Technical Specification[/url],此处是译文。
TrackBack 技术规范
名称
作者
版本
描述
发送一个TrackBack Ping
取回TrackBack Pings
TrackBack Ping URLs的自动发现
例子
TrackBack实现例程
自动发现的例程
变动
1.1 (2002年10月10日)
1.0 (2002年8月28日)
致谢
--------------------------------------------------------------------------------
名称
mttrackback - TrackBack 技术规范
--------------------------------------------------------------------------------
作者
Benjamin and Mena Trott, movabletype.org
--------------------------------------------------------------------------------
版本
1.1
--------------------------------------------------------------------------------
描述
本文描述了TrackBack, 一个点对点通信和网站间互相通告的框架. TrackBack的中心思想是TrackBack ping的概念, 从本质上讲，TrackBack ping是一个请求，通告“资源A与资源B相关，或有链接到资源B.” 一个TrackBack “资源” 用一个TrackBack Ping URL表示, 这是一个标准的URI.
利用TrackBack,站点间可以互相通告相关的资源. 例如，如果博客(weblogger)甲希望通知博客乙他写了一些有趣的/相关的/骇人听闻的文字，甲发送一个TrackBack ping给乙。这完成了两件事：
乙能自动列出那些引用他的某篇文章的网站，到他网站的访问者能读到网络上所有与此文相关的文章，包括甲的文章。
ping在他的文章和你的文章间提供了一种稳固的、直接的链接，而不是那种依赖于外部行为（某人点击那个连接）的非直接连接(如反向连接referrer)。
--------------------------------------------------------------------------------
发送一个TrackBack Ping
TrackBack使用REST(Representational State Transfer,http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)模式工作, 请求通过标准的HTTP调用传送。要发送一个TrackBack ping, 客户端向服务器端发送一个标准的HTTP请求，然后接收一个简单XML格式的应答(详见下述).
在TrackBack系统中，接收TrackBack pings的URL叫TrackBack Ping URL.一个典型的TrackBack Ping URL如http://www.foo.com/mt-tb.cgi/5, 其中5是TrackBack ID. 服务器端可以用任何有意义的格式来定义TrackBack Ping URL;客户端不应该只限于特定的格式.
为了发送一个ping, 客户端发送一个POST格式的HTTP请求到TrackBack Ping URL. 请求的内容的content type应是application/x-www-form-urlencoded. 例如, 到http://www.foo.com/mt-tb.cgi/5 的ping请求可能看起来象:
POST [url=http://www.foo.com/mt-tb.cgi/5]http://www.foo.com/mt-tb.cgi/5[/url]
Content-Type: application/x-www-form-urlencoded
title=Foo+Bar&url=http://www.bar.com/&excerpt=My+Excerpt&blog_name=Foo
注意: 在旧版本的TrackBack规范中，ping是用GET格式的HTTP请求发送的. 这种方式将不再支持; 2003年1月发布的Movable Type系统将会去掉对GET方式的支持。.
可能的参数包括:
title
文章的标题
excerpt
文章的摘要. 在Movable Type系统中, 如果摘录信息超过255个字符将会被截断为252个字符, 并在后面增加 ...三个字符.
url
文章的永久连接. 象其它永久连接一样，这个连接应可能准确地在页面中定位文章的入口，因有疑问时这个链接会用到。
blog_name
发表文章的blog的名称。
在Movable Type系统中, 在上述的参数中只有 url 是必须的. 如果 title 没有提供，, url 的值将被用作标题.
对上述请求的应答信息，以XML格式编排，从而能实现应用层的错误检查。(HTTP层的错误将会这样返回--例如，如果TrackBack URL 所指的资源在服务器上已经不存在，状态码404 将会返回).
一个成功的ping将会返如下应答:
一个失败的ping将会返如下应答:
当然，应用程序应该允许将来根据需要增加字段，但应答的 XML 结构保持不变.
--------------------------------------------------------------------------------
取回TrackBack Pings
要取回某个特定TrackBack Ping URL收到的ping,向它发一个GET格式的HTTP请求，请求字符串(query string)是 ?_mode=rss. 在规范的将来修订中，--一旦从POST转换到GET的过渡期结束--这将非常简单，向TrackBack Ping URL发送一个GET请求，将返回一列ping.
一个GET请求样例如下：:
GET [url=http://192.168.1.103/mt/mt-tb.cgi/3?_mode=rss]http://192.168.1.103/mt/mt-tb.cgi/3?_mode=rss[/url]
对此请求的应答，要么返回如上所述的错误信息，要么返回一列用RSS规范格式标志的TrackBack pings, 整个应答内容的覆巢无根元素是
例如:
http://this.is/the/trackback/item/link/
http://this.is/the/permalink/
在标签
--------------------------------------------------------------------------------
TrackBack Ping URLs的自动发现
TrackBack客户端需要一种方法，来确实一个特定的URL或blog文章的TrackBack Ping URL. 服务器在生成页面时应内嵌RDF; RDF 描述关于该文章的元数据，允许客户端自动发现TrackBack Ping URL.
RDF样例如下：:
xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
dc:identifer="http://www.foo.com/archive.html#foo"
dc:title="Foo Bar"
trackback:ping="http://www.foo.com/tb.cgi/5" />
注意: 由目前的检查器将嵌入XHTML页面的RDF信息视为不合规范，要通过检查需要将上述的RDF信息用注释符括起来:
这不是一个完美的解决方案，但是作为一个临时的应对措施它可正常工作.
其中的dc: 元素是标准的Dublin Core 元素; trackback:ping元素来自RSS 1.0/2.0的TrackBack模块，参见http://madskills.com/public/xml/rss/module/trackback/.
给定一个URL my_url, 客户按下列步聚来寻找TrackBack Ping URL:
发送GET格式的HTTP请求，取回 my_url对应的页面的内容.
扫描页面内容，查找内嵌的RDF. 页面中可能嵌有多处RDF--客户端要找到 dc:identifier等于my_url的那块RDF信息.
从RDF块中抽取trackback:ping值，这就是TrackBack Ping URL.
客户端一旦确实了TrackBack Ping URL, 它就可以发送TrackBack ping了 (参见 发送 TrackBack Ping).
自动发现的代码样例参见 例子.
--------------------------------------------------------------------------------
例子
TrackBack实现样例
为帮助那些有远见的开发人员在他们的系统中实现 TrackBack , 我们发布了一个TrackBack的独立的实现，它不依赖于Movable Type系统. 它可接收通过HTTP请求发送来的ping, 将ping存放在本地的文件系统中, 且可以返回某个特定TrackBack项(文章)的一列RDF格式的ping. 如果你要求，它还可以静态地产生 RSS文件. 例如，要将最近的15个ping列在工具条，这项功能就会泒上用场。
这个独立的TrackBack实现可从http://www.movabletype.org/downloads/tb-standalone.tar.gz下载.
它的发行遵循 Artistic License. Artistic License条款的描述在 [url=http://www.perl.com/language/misc/Artistic.html]http://www.perl.com/language/misc/Artistic.html[/url]
它的安装和使用指令说明在http://www.movabletype.org/docs/tb-standalone.html.
自动发现的代码样例
use LWP::UserAgent;
sub discover_tb {
my $url = shift;
my $ua = LWP::UserAgent->new;
$ua->agent('TrackBack/1.0');
$ua->parse_head(0); ## So we don't need HTML::HeadParser
$ua->timeout(15);
## 1. Send a GET request to retrieve the page contents.
my $req = HTTP::Request->new(GET => $url);
my $res = $ua->request($req);
return unless $res->is_success;
## 2. Scan te page contents for embedded RDF.
my $c = $res->content;
(my $url_no_anchor = $url) =~ s/#.*$//;
my $item;
while ($c =~ m!(
my $rdf = $1;
my($perm_url) = $rdf =~ m!dc:identifier="([^"]+)"!;
next unless $perm_url eq $url || $perm_url eq $url_no_anchor;
## 3. Extract the trackback:ping value from the RDF.
## We look for 'trackback:ping', but fall back to 'about'
if ($rdf =~ m!trackback:ping="([^"]+)"!) {
return $1;
} elsif ($rdf =~ m!about="([^"]+)"!) {
return $1;
}
}
}
这段Perl定义了一个过程 discover_tb. 给定一个 URL, 它会试图找到与此URL相对应的TrackBack Ping URL. 如果找到了，它会返回 TrackBack Ping URL; 否则返回 undef.
--------------------------------------------------------------------------------
变动
1.1 (2002年10月10日)
在此版本中，TrackBack pings 的发送用 POST 格式的HTTP请求代替 GET格式的请求.旧版本的GET方式将不在支持，MT中从2003年1月起也不再提供对GET方式的支持。
在RDF中，现在TrackBack Ping URL应在trackback:ping 元素中保存, 而不是原先的 rdf:about元素.
修改了 TrackBack Ping URL的样例的格式，用 PATH_INFO 代替了请求串(query string).
内嵌的供自动发现使用的RDF不再导致页面检查时出错。
增加了自动发现的样例代码.
1.0 (2002年8月28日)
规范首次发布.
--------------------------------------------------------------------------------
致谢
感谢Paul Prescod和其他朋友，他们的指导让TrackBack更符合REST.
--------------------------------------------------------------------------------
Copyright © 2001, 2002 Ben Trott and Mena Trott. All Rights Reserved. Posted by Hilton at November 7, 2003 11:28 AM | TrackBack
Comments
Hi Chergen,
我用的blog引用你说这个blog的“实验室成员个人blog大爆发”，成功了（也麻烦你将它删除吧），也就是说它是可以接收trackback的。
是不是系统不稳定，你再试一下？
Hilton
Posted by: Hilton at March 4, 2004 07:24 PM
在Blog服务器http://www.etc.edu.cn/blog/（Moveable Type） 中的Blog中，发送引用通告时会显示出错了（实际上已经发送出去，目的地能够接收到），但是它本身不能收到其他服务器发送过来的引用通告！请问这是什么原因，以及怎么解决。
希望能得到你的解答！谢谢！
Posted by: Chergen at March 4, 2004 07:06 PM
看的非常犀利糊涂，不知道在程序里如何实现
Posted by: kimjooy at November 14, 2003 09:55 AM
看了你的这两篇教材，开始多少对trackback有些了解了！
谢谢你的共享！
Posted by: tsingove at November 13, 2003 01:14 PM
从这个规范的定义来看，trackback系统是在两个支持tb的两个web服务器之间互相传递信息的一套机制。传递的信息有两类：
一是引用信息，以ping发送，数据包中可以含有 title、excerpt、url、blog_name等内容，其中只有url信息是必须的。这类信息，主要是想告诉对方，我这儿有一篇什么样的文章（如标题为何，摘要是何，URL是何等）引用了你的哪一篇文章（POST信息到的目标URL，已经指定了是哪篇文章了）。
另一类，是从某个站点取回这个站点的某篇文章收到的所有的引用。有了这个功能，你就可以找到所有与你兴趣相投的文章了（只少它们都引用了这篇文章）。
至于当你收到某人发来的ping时，如何处理，要不要显示，显示哪些内容，要不要分类，要不要计数，则是个人的自由，规则没有作规定。
不过有一点，就是没有必要分析referer，一是因为这个ping包中本身就有url信息，二是这个请求是web服务器发出的，请求头里可能没有referer信息。
还有一点，就是从规范中可知，trackback系统中，每篇文章有两个URI，一个正常的可以访问页面的URL，另一个用来接收ping的URL（即所谓trackback ping url)，至于后一种URL如何设计，规范也没作规定，只要这个URL中的信息能区别出是那篇文章，即可。
以上是我的理解，供参考。
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
TrackBack新手指南(编译)
[url=http://hedong.3322.org/archives/000350.html]http://hedong.3322.org/archives/000350.html[/url]
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
March 18, 2004
Blog、IM、MSN机器人
Blog、IM、MSN机器人
(2004.03.16) 来自：Chinabyte 张翼轸
近期的IM业界实在是热闹，先是做IM的腾讯和做校友录的搜狐互相捞过界，接着又出了一个IMU，以开放式体系吸引合作者一起成长，而如今又有了一家叫www.golb.cn的网站在推出自家的blog服务同时，一并推出了支持RSS阅读和blog发布的IM软件。毫无疑问，越来越多的网络应用正在努力的和IM融合，寻求新的成长空间。
还是让我们先来看看golb.cn推出的IM软件GOLB BLOG TOOL。相信对于不少blog的研究者而言，这个软件的推出应该是一件令人愉快的事情——他们很早就在猜测的blog和IM合作如今终究有人开始尝试了。不过如果我们对于这款工具的功能仔细审视，恐怕就不会有太多的喜悦。说到底，GOLB BLOG TOOL不过是由三个功能RSS聚合阅读，BLOG更新，MSN即时消息简单的雷加在一起，而缺乏足够的整合，其远远无法发挥出1+1+1〉3的效果。
是的，在blog和IM融合问题上，GOLB BLOG TOOL离我设想的相差太远了。虽然在不久前的一篇文章（《谁应该和IM合作？》）中笔者指出过IM的终端软件特性决定了它在执行很多应用方面比Web有更好的表现，但是如果IM软件只是满足于把其他的软件功能简单的累加在自身身上的话，那么这种累加除了把软件变得越发臃肿以外，能够收到的效果是极其有限的。正如笔者在另一篇文章（《当IM和同学录走到一起》）中所提及的，对于IM软件和其他应用的融合，社会网络的融合是最关键的。
在笔者的脑海中，blog除了是一个自由的发表平台以外，其通过彼此之间的链接构建起来的那个blogger关系网络同样也是其非常独特而引人关注的一个新特性。如果IM和blog要融合的话，那么基于IM的关系网络和基于blog相互连接的关系网络的融合也就应当是首先应当考虑的一个问题。
想象一下吧，当你在你的IM中添加了一位新的好友，这位好友事先登记的blog也会立刻出现在你的RSS阅读软件中，甚至每次对方更新了blog之后，无须RSS阅读软件的反复检查，blog服务商就会自动通过IM把更新的消息发给你；或者与此相反，当你在自己的blog中添加了另一个blog的链接，对方登记的IM帐号也会自动添加入你的IM软件，你在对方blog中留下的评论都会自动通过IM发送给对方，你们彼此之间除了blog以外还可以依托IM进行更加方便的沟通——如果你们愿意，沟通的所有内容也可以反向的补充在blog上，供其他人参阅。
这样的一套应用，是不是比起现在简单的功能累加要来得有趣得多？是的，一切的关键就在于不同软件融合的不仅是他们的功能，更重要的是他们彼此的网络，从而发挥最大的效用——而这正是GOLB BLOG TOOL目前所匮乏的。
事实上，GOLB BLOG TOOL引发我思考的，不仅仅在于其IM和blog融合的思路，更在于其融合的第三条道路的选择。从已有的案例来看，Web应用和IM融合融合，搜狐的校友录走的是完全开发自己的IM软件从零开始的道路；IMU的思路非常具有创新性，它力图将自己的IM平台半公开化，让其他的合作者能够利用定制版或者插件的方法简单的完成融合——就个人观点，在技术上这是最理想的方法；而GOLB BLOG TOOL无疑是第三道路，通过纯粹与现有IM软件兼容的方法来实现融合——与其他一些一方面兼容其它IM软件一方面发展自己的IM软件，把兼容作为抢夺份额的敌意行为不同，这种融合只不过是在原有的基础上增加了一些与IM无关的功能，可以看作是一个新的Shell，一种善意的兼容。
对于这种第三道路，有的用户表示颇为不解，GOLB BLOG TOOL为什么不以一个MSN插件的方式发布，而是要制作成一个全新的MSN Shell。的确从用户的角度来说，在功能一致的前提下，我宁可选择装了插件的MSN也不要另外一个MSN Shell——插件可以装几个，Shell却只能用一个，有局限性。在这一点上，笔者也持同样的看法。但是笔者认为更值得我们思考的事，为什么在IM与WEB融合的问题上，我们一定要纯粹的从客户终端角度去思考，老是想着要在用户的终端软件上做点手脚呢？其实有另一种方法可能成本更低，而且更加有创造性。
你有玩过MSN机器人吗？没错，我说的就是从它身上发展出来的思路。所谓MSN机器人，其实也是一个与MSN兼容的Shell，但是与其他的Shell必须由最终用户安装不同，MSN机器人是采取类似服务器的安装方法，你在自己的服务器上安装这个Shell，并且利用对应注册的MSN帐号上线。其他的用户只需要把对应的MSN帐号加入自己的MSN好友，就可以通过类似以前DOS命令行的方式进行互动，从而获得MSN机器人需要的消息。如果把这个思路发展一下的话，就会发现很多好玩的应用。
还是以电子邮件为例吧。假如我是XXX.net这个电子邮件服务商的用户，XXX.ne基于MSN推出了一个IM邮件提醒的功能，只需要对方的MSN机器人把我的MSN帐号加为好友，并且把这个帐号和我的XXX.net邮件账号绑定，那么一旦我的邮箱有了新的邮件，XXX.net架设的机器人就会通过MSN 短消息告诉我有了新的邮件，大致的内容是什么。这是不是一个非常简单而且使用的IM和WEB应用融合的范例？要知道，这种融合的方式既不需要改变用户的客户端，也不需要在用户的客户端上增加什么插件，只需要用户被作为一个好友添加，一切融合就由此开始了，这是不是一种非常简单而且有效的方法？当然，这种融合方法的一个重要缺陷就在于MSN 消息只能是文字或者图片的，这个就局限了融合的应用，不过即使如此，对于许多的WEB特别是新闻、资讯网站，即使是这种程度的融合，也足够能够开发出许多实际的新应用来的。
事实上，目前阻碍这种思路实用化商用化的一个巨大阻碍就在于MSN的先天限制。在这里，我并不认为对于MSN通信协议的逆向工程利用会是一个问题（微软仅仅公开过MSN最初的通信协议，但是此后一直到如今V10的通信协议都是保密的），因为前面已经说过了，这是一种良性的兼容，微软恐怕应该鼓励才对。真正令人讨厌的在于MSN武断的最多150个好友的限制。要知道，我们目前看到的诸多MSN机器人都是被动式的，只需要用户添加他们，所以每个机器人的服务限制只是受到程序的负荷影响（比如机器人小布是每个3000人），但是笔者刚刚提及的那种与WEB应用融合的MSN机器人是主动式的，必须主动添加用户的MSN才行，这样就会直接面对每个机器人只能为最多150个用户服务的问题，对于那些有上万甚至几十万用户的服务上岂不是要同时启动成百上千个机器人才行。虽然150人的限制其实只是技术上的一个强硬规定，但是考虑到微软的实际情况，恐怕其不太可能为了一些MSN机器人的新应用而有所改变。
如此一来，就只能期望国产的IM软件能够有所行动了。目前关产的IM软件UC已经有了类似MSN上机器人小布的被动式机器人，但是主动式的似乎还没有看到。至于QQ，似乎还没有什么太大的动静。其实笔者最寄予希望的还是IMU，既然其上场就是以开放的合作平台作为重要的卖点，那么类似主动式IM机器人这样的新应用，其应该是乐于见到而且加入到现有的发展战略中去的——毕竟比起用户定制版、插件这两种开放形式来，主动式IM机器人更加简单，更加方便。
摇旗呐喊晚了，笔者在这里也就只能拭目以待，看看第一个与WEB应用融合的主动式IM机器人服务究竟花出谁家了。
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
March 10, 2004
谁应该和IM合作？
[url=http://www.blogchina.com/new/display/25249.html]http://www.blogchina.com/new/display/25249.html[/url]
作者：张翼轸 2004-3-10 9:21:57
出处：博客中国(Blogchina.com) b25249c
前几日写了一篇关于IMU道路思考的文章，虽然大致把个人的思考表达了清楚，但是因为篇幅的限制，并没有能够展开讨论一个对于IMU未来发展的重要问题——为什么应该和类似IMU的IM合作，应该怎样合作？今日再撰一文，作为补充。
IMU还没有正式推出，目前只是一个友情测试版，可是我们在它的首页上便已经可以看到合作伙伴听说过的，没有听说过的已经达到了数十家。当然，现在所说的合作，还只是一个意象，就像你家店铺开张，有朋友送个花篮过来祝贺那样，表表心意多过实质的行动。要观察这些合作伙伴究竟能够和IMU一起闯出什么名堂来，至少还要等到第一个合作伙伴定制版IMU（功能上有突破的）推出以后才能说。
所以，目前笔者只能从理论上的角度来分析一下合作的原因和可能形式。
为什么那么多以网站起家的合作伙伴都会看重IMU的潜质？笔者认为一个重要的原因其实就在于如火如荼的WEB方式有着先天缺陷，而这个先天缺陷恰恰是以IMU这样的IM终端软件所能够弥补的。
第一个缺陷：非本地化。WEB方式当年最吸引人们的就在于它只需要一个浏览器，所有用户获得的都来自服务器，HTML及相关技术的出现大大简化了对于用户使用网络的技术要求，为网络应用的普及带来了不可忽略的影响。但是这种架构的实现以及对于安全性的保证，限制了其在用户端的信息存储（cookies是一个很有限的例外），这也就意味着即使是完全一样的信息，用户每次需要使用也都需要每次从服务器下载，其效率与允许本地存储的终端软件“一次下载，反复读取”的方法相比，其效率无疑地下了许多。虽然宽带的出现一定程度上缓解了多次需要多次读取的时间浪费，但是宽带无论如何发展，短期内要超越本地硬盘的速度似乎都是一件不可能的事情。而HTML技术的先天限制也决定了即使是同样的表达效果，其执行效率也无法与使用高级语言编写的本地终端程序相比拟，这样使诸如Java这样的小程序出现的一个重要因素。但无论如何修修补补，为了实现其通用性，WEB应用在表现的丰富性以及实现效率上是无法与基于本地的终端程序所比拟的——一个很好的例子就是WEB Mail无论多么普及功能多么强大，但是大多数高级用户仍旧喜欢使用EMAIL终端软件来收发MAIL。
但是，如果我们为了WEB的这个缺陷，把所有可以基于WEB的应用都终端化，又会遇到一个当年WEB出现之前我们不得不遇到的问题，用户必须为了一个很小的应用安装一个终端程序，越来越多的终端程序最终将使得用户不胜其烦，同时也会使得用户的系统效率越发低下，所以我们会发现不少网络服务商都为自己的服务推出了终端板，可是如何说服用户再新安装一个终端而犯愁。而IMU的一个重要思路就在于把这两个问题很好的解决了起来——IM作为目前最重要的网络应用之一，用户已经接受而且多半会把其作为一个不可或缺的网络终端，那么其他的网络应用就无需再设计新的网络终端程序，而是可以作为IM程序的一个定制版本或者一个插件的形式来实现，这样终端程序永远只是IM软件一个，可是可以实现的功能却可以不断的扩展，充分发挥终端程序的优势。
第二个缺陷：非即时性。严格来说，几乎不存在真正的即时通讯应用，IM只不过把终端软件与服务器互动的间隔缩小到很小的几乎可以忽略不计的时间单位而已。但是正像我们平常在实现中所感受到的那样，IM软件的即时性实现得很好，而绝大多数力图使用WEB来实现即时性的应用就效果来说始终不如IM软件。而这正是IM软件一个独家的优势所在。相信大家对于MSN已经非常熟悉了，这款IM软件一个让许多用户心动的功能无疑就是其EMAIL到达提醒功能，一旦你的HOTMAIL信箱收到了邮件，你的MSN Messager立刻会提醒你。以往类似的功能，一些MAIL Checker软件也可以实现，但是方法却是按照用户设定的时间间隔通过POP3协议去收取邮件，一方面做不到真正的即时性，另一方面执行的效率也十分低下。而MSN把MAIL Checker的功能通过IM来实现，不但达到了即时提醒的效果，而且执行效率非常高，仅仅在邮件到达的时候接受服务器的信息，并且发出提醒，平常根本不需要像普通的程序那样反复检查邮箱的情况。
如果读者对于前几年的IT发展使还有些印象的话，就应该明白其实上面谈到的问题其实就是当年关于信息获取究竟是用户主动的Pull（拉）为主好呢，还是以服务器主动的Push(推)为好呢？虽然当年的争论支持Push(推)并没有过得太多的市场认同，但是如今有了IM这样的一个终端平台，Push(推)再次大展宏图并非没有机会。
正是基于WEB上述的两个缺陷，使得笔者相信IMU这样以终端化，以IM终端化的形式为合作伙伴提供除了WEB以外的表现形式是可能获得众多服务商的认同的——终端软件的便利性以及IM终端的即时性是可以帮助他们提供更加友好的人机界面及功能，从而取悦用户的。
那么，具体的这种合作究竟可以哪几种形式出现呢？以下是笔者个人思考觉得可能的形式：
一、 与EMAIL服务商合作。其实我们之前已经提及过了这方面的优良先例——MSN Messager和Hotmail的无缝连接。但是MSN Messager的问题就在于其只支持自家的Hotmail和MSN信箱，而无法同时支持其他服务商的邮件服务。但是IMU目前的平台却为此提供了可能性，假设笔者目前使用的是XXX的邮件服务，那么XXX只需要和IMU合作，利用其提供的开放借口制作一个插件，笔者只要在自己的IMU上安装好这个插件，并且设置好信箱的基本信息，那么以后笔者的这个信箱只要一有了新的邮件到达，这个插件便会立刻获得服务器的消息，然后通过IMU告知笔者。甚至笔者还可以通过这个插件直接浏览邮件，决定是否需要删除，甚至直接简单的回复，而不需要劳驾庞大的邮件客户端软件。
二、 与论坛服务商合作。对泡论坛的人而言，最关注的莫过于有谁回复了自己的帖子。以往要想知道这个，无疑就需要频繁的更新自己的帖子，查看是否有人更新，如果需要查看的帖子一多，反复切换刷新就十分麻烦了。即使有的论坛程序比较智能，可以在一个特定页面监控所有帖子的回复情况，但是你也仍旧需要不断的刷新这个页面。而这个论坛服务商如果能够推出IMU的插件，一旦有回复的帖子，那么就立刻可以通过IMU的终端告知，甚至可以把回帖的程序作为插件的一个功能，方便用户在无需开启浏览器的前提下，不离开IMU就能完成回帖的功能。
三、 与校友录合作。这个问题其实笔者在之前的文章中已经谈到过了，目前腾讯在IM的基础上推出校友录产品；Dudu.com一开始就推出IM和校友录紧密结合的产品，但是用户有限；搜狐校友录最有优势，可是其推出的IM产品实在糟糕，融合性也差。其实完全不需要推出自己的IM产品，通过和IMU产品合作制作插件的方式来推出也许是更好的选择，对搜狐而言可以降低开发IM产品的费用，对用户而言可以少安装一个终端软件——为了方便的是用校友录而选择特定的IM产品我未必愿意，但是把其作为已有IM产品的一个插件，我是绝对欢迎的。
其实IM终端和现有WEB服务的合作方式很多样化，上面只是举了几个常见的应用来说明，其实笔者还想到了很多其他的合作方式，比如和网上连载书站、和网上银行、和易趣拍卖网等等，不过实现原理和形式都差不多，这里就不详细说了。
我相信IMU目前想做的是一件非常重要的事情——那就是让IM软件取代浏览器成为我们上网的起点以及最常用的主要工具。当然，这是一个任重道远的过程，也许仅仅依靠IMU一家是不够的，希望能够看到更多的IM服务商能够加入进来，一起推动这个方向的发展——至少在国内，网易泡泡和腾讯QQ这些IM的先行者都是可以及早加入的。
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
杀人的艺术--对于杀人游戏的社会学解释
[url=http://www.blogchina.com/new/display/575.html]http://www.blogchina.com/new/display/575.html[/url]
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
March 03, 2004
大学十年（一个程序员的路程）
[url=http://www.access-cn.com/Article_Show.asp?ArticleID=53]http://www.access-cn.com/Article_Show.asp?ArticleID=53[/url]
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack
March 01, 2004
推荐Jabber，可以与blog配合使用
Jabber是什么?
是另外一个开放式网络信息通讯工具,她可以跳出各种商业即时聊天各自为阵的限制.使用她可以搭建自己的服务器,与其它现有的服务器一起构成全球分布式服务网络!并且可以用她与现有的常用即时聊天工具直接聊天,这样你不必为使用这个新工具而失去在MSN\YahooMsg\ICQ上的朋友,也不必同时或分别打开Oicq\MSN\YahooMsg\AOL等多个工具软件去查找你的朋友是否在线.虽然由于这些公司的抵制,一些相关的服务被封掉了,但相信开放协议的威力一定会战胜这些商用的封闭机制,开放意味着越来越多的机构和组织的主动加入，而每个服务器的加入都在增加了jabber的用户群的整体数量，具备系统发展自组织正反馈形成的特征．
另外,更重要的是,她还可以作为Blog的客户端:即时获得你订阅的rss更新通知、并可以通过她远程发布到你的blog网站。本站所用的两个系统(nucleus和drupal)就有这个潜在的功能接口,但现在尚未测试安装.现有的各种blog网站系统都已经或正在开发支持jabber协议的插件．
可以预见一下将来，一种支持jabber协议和在这个协议基础上同时支持blog-api和rss协议的新的网络工具将代替现有的即时通讯软件和浏览器软件，成为每个上网人通向网络世界的入口，既可以自由上网浏览，还可以保存记录自己浏览轨迹(甚至搜索记录)到你自己的私人网络区(而不是现在依赖于客户端)，可对任何感兴趣的网页发表评论保存到自己的blog中，还可以与他人即时沟通分享信息．
下面一篇文章转自
27floor blog
2003-10-23 眼下即时通讯的功能越来越被企业界看好，以资本无穷的力量，被它看上的东西很快就会收归旗下，这趋势一直以来就是很明显的：前面有QQ收费，有腾迅不允许别人开发Linux下的QQ插件，近来还有微软的Office 2003，在这款Office系统中，IM占据了一个非常重要的位置，几乎所有的应用都同IM绑在一起。而且微软也有自己的企业版IM服务器，可以让企业搭建自己专用的IM系统。有这样的例子，MSN以后会走什么的路线就很难说了。而且微软已经发过消息说不允许别的客户端连接MSN，虽然这话到现在也没有成为现实，可危险永远存在。
Jabber正是这么一种对抗的力量，它是个开源项目，架构、协议全面公开，并且基于XML。而且它还是个分布式的系统，也就是说你可以架自己的Jabber服务器，注册到这台服务器的用户一样可以同其他地方的Jabber服务器上的注册用户联系。比如主站Jabber.org上的用户A，他的联系名是这样的：A@jabber.org，就像电子邮件地址，它可以同B@amessage.info联系，后一台服务器似乎是在德国。这样就构成一个分布全球的Jabber网络。同时，每个企业也可以建立自己的Jabber服务器，并且封闭外部接口，只供自己内部使用。-->>>>>>>>>>>>
Jabber设计的理念是服务器端尽量复杂，功能多样，而对客户端要求较少，这样许多功能都可以在服务器端实现，而客户端可以不管，甚至可以从客户端直接发送XML代码过去实现一些功能。
正因为如此，Jabber也可以通过服务器插件的形式实现同其他IM系统，如ICQ、Yahoo、MSN的联系，但这要求你注册的服务器安装了这些插件。但这些公司似乎都不愿意这样做，如Jabber.org就被他们封掉了，而不能提供，而amessage.info就还没有，有所有这些服务。
信息技术的发展已经到了协同工作的时代，正如MS office所表明的那样，可现在国内的企业似乎都处在个人单机工作的时代，距离还很大。但Jabber的特点表明它可以构建你想要的任何应用，比如同Office集成一下什么的。它开放，又基于XML，前景是很好的。目前Jabber基金会已经向IETF提出了一个标准，不知道同W3C或OASIS有无冲突。
在校园里有人在推UU校园通，它实际上也是个基于Jabber的系统，不过中文版居然不声明这一点，但它的客户端可以连接Jabber服务器的。
我的Jabber账号：qi at jabber.org/amessage.info
2003-10-23 09:51:21，由cathayan发表。目录：General
得分： 31 [ － | ＋ ] 浏览 301 次
Comments
Zoom.Quiet 说：
收到!
感谢您的指引!
FLOSS 事业实在发展的太快,都有些难以选择了!
再谢!
是从Windix’s Weblog 得知此处的!
于 2003-12-06 17:56:35 发表
Zoom.Quiet 说：
嗯嗯留个油箱!
于 2003-12-06 17:57:18 发表
小文 说：
太多好的选择了，有点眼花的感觉。嘻嘻……不过非常感谢能得知。
于 2003-12-09 18:45:30 发表
adpu 说：
这个可以说是超级好。协议开放，跨各种平台，分布式，支持XML，不论是个人用户，还是想整个IM平台的中小企业来说都是不二之选。
于 2003-12-09 20:04:56 发表
good! 说：
我也强烈推荐它!这是属于我们用户的即时通讯！
Posted by ch1v4n at 09:56 PM | Comments (0) | TrackBack