级别： 初级 Edd Dumbill (edd@xml.com), 编辑兼发行人, xmlhack.com
2003 年 9 月 01 日 在本文中，Edd Dumbill 向我们介绍了 Dashboard。这是一种实时连续桌面信息检索引擎，它目前正在迅速地引起第三方开发者的注意。Dashboard 通过使用简单的 XML 消息传送，使之与其他应用程序的集成变得更加快捷。
您已经听过很多关于在企业内部以及 Internet 上传输 XML 消息的情况了吧，不过 XML 消息在桌面系统中的应用还不是很多。但这也没什么奇怪的，因为操作系统中使用的各种各样的远程过程调用（Remote
Procedure Call，RPC）系统已经牢牢占据了这一领域。因此，对这些系统进行变革的需求也不很强烈。除此之外，负责操作系统消息传送策略的开发人员倾向于对
XML的复杂性持怀疑态度。
但是如果您的应用程序需要与其他的应用程序对话，并且需要在很短的时间内实现互操作，您又该作何考虑呢？在这种情况下，您会突然发现 XML 原来有这么多优点： 支持它的工具无处不在，通过 schema 可以很容易地共享合法的消息，并且 XML 的纯文本格式使得为它编写文档十分简单。
当 Nat Friedman 和他的开发伙伴们（参阅
参考资料）开发 Dashboard 的时候，碰到的正是这样的情况。Dashboard
是一个开放源代码的应用程序，可以提供连续的实时桌面信息搜索，用来随时向您展示与您正在计算机上从事的工作相关的信息。Dashboard 与其他应用程序的集成，在很大程度上依赖于它能很容易地修改那些应用程序以便和它们通信。
Dashboard 是做什么的？
Dashboard 从关注的应用程序接收上下文信息，并使用该信息来查询后端存储的选集。比如说，当您阅读电子邮件的时候，邮件客户端会将与您通信的电子邮件地址、信件主题以及正文内容发送给
Dashboard。然后，后端存储会搜索与之相关的信息（比如后端地址簿会打开来信者的一张地址卡片），然后将这些信息返回给 Dashboard
的用户界面。如图 1 所示，用户的移动电话上收到一条从 Edd Dumbill发来的文本信息，然后 Dashboard 就会将它所存储的这个发信人的相关信息显示出来：
图 1. Dashboard 运行界面
Dashboard的应用场合很多。对于桌面系统来说，用户经常会迷失在一个数据孤岛的集合中，每个孤岛都被数据所属的应用程序所束缚。Dashboard 为这样的应用程序提供了统一的通道，使用户有机会从每一种应用程序的数据中获得更多的价值。在商业环境中，很多日常工作都极大地依赖于上下文信息和相关信息。比如说，在客户关系管理（Customer
Relationship Management）系统中，销售人员必需能够随时掌握与他们正在应付的客户相关的全部信息。
Dashboard 最关键的地方在于，它依赖桌面应用程序能够向它发送提示，用 Dashboard 中的术语来说，就是发送
线索（
clue）。从这个角度来看，只有当您强烈依赖整个桌面（比如
Max OS X），或者在您可以自己修改相关应用程序的开放源代码世界，使用 Dashboard 才是可行的。对于后一种情况而言，Dashboard
目前的目标是支持 GNOME 开放源代码桌面系统，并且已经成功吸引了一大群人（包括本文作者）编写新的代码与之交互。
图 2 显示出 Dashboard 的总体架构图，这张图详细阐明了数据在用户应用程序（user application）、Dashboard 主引擎以及专用的可查询数据存储后端（back
end）之间的流动。
图 2. Dashboard 架构综览
目前，Dashboard 是用 C# 编写的，可以在安装有 Ximian 的 Mono .NET 运行库（参阅
参考资料）的
x86 Linux 机器上运行。它是一种试验性的软件，尚未正式发布（希望在您对它的架构进行太苛刻的评论之前牢记这一点）。不过这个软件还是吸引了很多开发和评论人员的注意力。当今年的
O'Reilly Open Source Convention（O'Reilly 开放源代码大会）首次演示完 Dashboard 的时候，展厅里的讨论声就不绝于耳，甚至是对
Linux 桌面系统持怀疑态度的 Tim O'Reilly 也在开始琢磨，为什么 Mac OS X 上还没有出现像 Dashboard 这样的产品呢。
Dashboard 的 cluepacket
那么应用程序是如何告诉 Dashboard
它们正在做什么呢？这就要归功于
clupacket（线索包）。cluepacket
是一个 XML 文档，其中携带了类型化的上下文信息。cluepacket
从用户的应用程序中发出，然后由 Dashboard
引擎分发给每一个后端。如果有哪个后端取得的数据与
cluepacket 中的数据相匹配，这个后端就会以 HTML
的形式返回结果。它还可能向 cluepacket
中加入新的元数据，这样其他的后端就可以获得更好的结果了。
清单 1显示了
图 1 描述的Phone Manager（电话管理器）发出的 cluepacket。Phone
Manager是我写的一个应用程序，可以用蜂窝电话发送和接收文本信息（参阅
参考资料）。
清单 1. cluepacket 示例
<CluePacket>
<Frontend>Phone Manager</Frontend>
<Context>Text Message</Context>
<Focused>True</Focused>
<Clue Type="phone" Relevance="10">+447867093093</Clue>
<Clue Type="textblock" Relevance="10">
Will you email john@smith.com with today's
schedule? Thanks.
</Clue>
</CluePacket>
|
您可以看到，cluepacket 携带的元数据的主要内容是该cluepacket的来源，以及其中包含的每一条线索的类型、相关性和名称。所谓的
cluetype
的列表目前还在增加之中，其中包括：
- 日期
- 人的全名
- 电子邮件
- 聊天 ID (
aim_name ，
yahoo_name ，
msn_name ，
icq_name ，
jabber_name )
- org
(组织名称)
- 地址
- url
您可以从
参考资料中找到更完整的内容列表。
某些类型的格式是相当自由的，这可能会给那些通过 schema 对数据进行控制的 XML 开发人员带来不便。不过如果您以为可以在一夜之间统一桌面应用程序的信息结构，那未免也太天真了吧；即便真的有一天统一起来了，您还得面对人们输入信息的不一致。Dashboard
采用的方法是获取粗粒度的输入信息，让后端查询引擎来决定哪些信息是重要的。这样的方法看起来挺合理，其中的一部分处理过程也是从 Google 的
Web 搜索方法中借鉴来的。不过由于我对元数据一直很着迷，所以我觉得，这种方法没有在它们实际可用的时候，将可管理的丰富元数据记录下来，似乎有一点儿可惜。
当前，用来传输这些cluepacket 消息的协议是简单的 TCP/IP socket。应用程序连接到localhost上的 socket，发出
XML，然后关闭 socket。而这么一种简单方法背后的理由，似乎就是为了实现起来方便：要编写任何一种类型的信息搜集器，最困难的问题就是从提供数据的程序获取大宗数据。Dashboard
中包含一些例子，可以说明它的实现方式。有了 Dashboard 的便利的函数，我只需要用 C 编写很少的几行代码，就可以在电话管理器中增加对
Dashboard 的支持。
图 3 显示了通过 Dashboard 增强 Web 浏览器功能的屏幕画面。图中的浏览器正在浏览我个人的 weblog。浏览器将 URL 和 HTML
正文内容发送给 Dashboard。某个后端程序扫描了这个 HTML，从 段中找出若干关键字，然后将这些关键字与我的 “RDF 网站摘要（RDF
Site Summary，RSS）”与 “FOAF（friend-of-a-friend）文件”相关联。输入的线索中现在加入了新的线索类型：keyword、rss、foafid以及
rdfurl，然后其他的后端就可以使用这些线索了。随后，书签后端用关键字与我的书签进行匹配，接着 RSS 后端接收到我的网站上最新的四篇文章，FOAF
后端显示出我的个人信息。
图 3.用 Epiphany Web 浏览器和 Dashboard 增强的 Web 浏览功能
后端与桥接
图 2
中左边的通信方式与右边不同。虽然用户应用程序与
Dashboard 之间的单向通信是通过简单 XML 消息传送实现的，但是右边的通信则是利用 C# 的方法调用。也就是说，所有的后端必须在
.NET 中实现（现在说来，就是必须用 C# 实现）。Dashboard 通过运行时反射技术实例化并调用它在运行的时候发现的每一个后端。因为后端查询可能要花费一定的时间，特别是在需要通过复杂查询或是需要访问网络才能得到结果的情况下，花费的时间会更长，因此，后端查询是在线程中并行执行的。
前面我提到过，Dashboard 中存在一种古怪的不平衡现象：您可以用任何语言发送 cluepacket，但是只能用 .NET 这一种语言作为后端。为了解决这一问题，以及与
Web 应用程序连接，我编写了一个简单的桥接类，它可以用 HTTP POST 将 cluepacket 重新广播到 HTTP 服务器上。cluepacket
将作为 POST 的一个参数发送，返回值可以是 HTML，或者是 XML。（目前，我的代码效率还很差，它发送了两遍 POST，一次用于请求
HTML 结果，一次用于请求所有的 XML 线索参数。）这个桥接类的代码可以从 GNOME CVS 中下载（参阅
参考资料）。因为很多应用程序框架都可以公开
HTTP 服务器的接口，所以 HTTP 桥对于与现有系统集成而言可能非常有用的。
结束语
在将桌面系统的的数据孤岛集成在一起这个问题上，Dashboard 迈出了可喜的第一步。它对XML的使用可能很好地预示着XML今后将如何进一步解放桌面数据。为了使
Dashboard 最大程度地得到采纳，它的创作者做出了一些有意思的选择：
- Dashboard 避免了谋求尽善尽美，而是采用了实验性的开发方法。
- 为了得到简单可行的解决方案而避免了过度设计（Over-engineering）。命名空间、RDF以及 URI 都可以像这样很容易地加入到应用程序中，但是如果在一开始就把注意力集中在这些问题上，则会使最重要的用户应用程序工具的可用性降低。
- Dashboard 中使用了 XML 和异常简单的网络协议，使得通信各方很快就位——对于为找出Dashboard
引擎需要什么架构而进行的实验来说，拥有可用的源数据是至关重要的。
当统一桌面尚未成熟的时候，人们很有可能在大量的实验之后发现不得不抛弃 Dashboard。不过在目前，由于开放源代码、简单基础结构以及 XML的结合，意味着
Dashboard 正在吸引大量的注意力和贡献者。
参考资料
关于作者
对本文的评价
| 
