MarkMail将邮件列表存档推向新境界

去年年底,MarkLogic发布了MarkMail。MarkMail是一款专门提供免费邮件列表档案搜索的工具，基于他们的MarkLogic XML服务器。最初发布时，它仅支持搜索apache.org邮件列表，最近，Mozilla.org，PHP以及MySQL列表也加入其中。O'Reilly的Rader在上个月针对MarkMail发表说：

……MarkMail提供的不仅仅这些，还有更多的东西。MarkLogic存储了近550万的邮件信息，涵盖了700多个开源的邮件列表——所有Apache，MySQL，Mozilla，以及PHP的列表，还有其他一些列表，随着时间的推进还会有更多列表加入（希望很快就能实现）——并且它的用户界面比google搜索漂亮。它运行起来也一样很快，甚至更快。但更重要的是，你可以有内嵌数据挖掘功能，我相信最终更传统的邮件系统也会引入这个功能……MarkMail真正的闪光点在于管理大量的邮件存档。这当然也是MarkLogic将MarkMail作为免费工具的原因。MarkLogic知道潜在的客户群就是那些拥有巨大的邮件存档想要对存档做数据挖掘的公司，而他们的现存系统的性能根本办不到（更不用说用户界面了）。

InfoQ和MarkLogic的Jason Hunter 坐下一起探讨目前的详细状况以及未来的发展方向。

请问您是否可以给我们一些尚且不太了解的读者简单地讲一下什么是XML上下文服务器？

XML内容服务器就是为内容而建的数据库(相对于为数据而建来说)。内容是文字的，有层次，但通常不存在重复性的结构。它经常使用XML来编码。举例来说，像书，文章，网页，博客日记，以及邮件信息等等都属于内容范畴。

我们开发的MarkMail建于MarkLogic服务器之上，该服务器是一个商业化的XML内容服务器。MarkLogic服务器有一个事务仓库（transaction store），但它并不以表的方式来思考，取而代之以XML的方式思考。在MarkMail中，每个邮件都被当作一个XML文件。你所看到文本搜索，分页导航，分析性查询和HTML网页的处理都由这单个MarkLogic服务器机器来运行处理上百万个XML文件而完成。

为什么说对于邮件，XML的格式比关系数据库管理系统来的更好呢？

我曾在基于关系数据库的邮件查询系统上工作过，我可以这样告诉你，由于邮件的自然属性，那实在是一个挑战。邮件是凌乱的，是文字化的，是没有规律的，并且自有它的层次。这些都是对于传统以关系为核心的数据库的挑战。

邮件报头是有非常好的结构的，但并不完美，并且在任何域上都不存在固有的大小限制。邮件体本身可能看起来只是纯文本（所谓无结构式），但实际上并不仅仅这样。它有段落，嵌套的引用段落(A引用B的言论），开头的问候语，以及信末的署名。它们还时常有附件，在附件中还有成页成页的像文字、段落这样的东西，所有这些一层一层地组织起来。

通过MarkMail，我们将每一个邮件都作为XML文件导入MarkLogic服务器。这对于邮件来说是非常自然的格式。我们标识出邮件报头、邮件体的段落、引用、问候、信末署名等等，几乎是标识一切，甚至是附件和附件的内容。然后，通过采用XQuery作为一种能够理解XML的查询语言，我们可以创建一个系统来使用前面标识出的结构。

我们使用内部XML结构实现了很多目的。比如，在作基本查询的时候，我们就略去了信尾例行公事的签名。我们能做到这点是因为我们能识别出它是什么。

当然有时候你想要将这些信尾文字包含进来，实际上可能仅仅需要这些信尾，比如联系方式的信息查询服务。想象这样一个服务，你只需要提供给我们一个人名，我们就可以从他的信末签名中为你取得他的联系方式，并将他最近的联系方式显示于最上方。我们能做到这点是因为我们可以将邮件体中的结构（没有规律和无法推测，但仍然存在的结构）和元数据的结构（更有规律但仍不可完全推测的结构）结合起来，最终得到是谁发送了这些邮件，他又是在什么时候发送这些邮件。

另一个例子是我们的opt:noquote选项。这个选项的意思是你想要在原文并只在原文中找到匹配的文字，而不是在引用的段落中匹配。以这样一个搜索举例来说：

"godwin's law" opt:noquote

它可以查找到邮件发送者在哪里写有这样的词组“godwin'slaw”，并且将那些发送者仅仅引用了这个词组的邮件忽略不计。因为我们能识别出邮件中的引用结构，所以是非常简单的。我们还可以引用结构来做其他的事，比如在显示邮件的时候用不同的彩色来区分。

再举个例子，我们使用结构来处理附件。试一下这样一个搜索：

extension:ppt axis

这样一个搜索可以查找到包含文件扩展名为PPT的附件，并与axis（一个Apache网络服务项目）相关的那些邮件。在搜索到的邮件结果中，你可以看到我们不仅知道哪些附件含有“axis”，我们还也知道有多少张幻灯片，在你查看附件的时候我们会在搜索命中的幻灯片下添加下划线。这些都是可能的，因为那些看起来不存在任何结构的东西事实上包含了很多结构。

在开发MarkMail的过程中，关于MarkLogic服务器，你觉得最有趣的发现是什么？

在开发MarkMail的过程中，我们决定更激进一点，不使用Java、Ruby、Python、Perl 或者任何其它传统网络开发语言来开发站点。我们实际开发采用了XQuery，这是一种W3C组织定义的以XML为核心的语言。

想象一下一个传统的Java网络应用软件是如何工作的。你的数据被储存于关系数据表中，将事物编程为对象，并因为网页浏览器的缘故将对象转换成结构化的HTML。这个过程里存在双重的阻抗不匹配，实在很痛苦。这也是为什么每个月都有新的ORM工具和网络开发框架(framework)诞生并且许诺会消除痛苦。

通过使用XQuery，我们在各个层次保持一个统一的以XML为核心的视角。我们的模型是以无数的XML文件来存储邮件，我们的控制器是XQuery以及它本身对XML的支持，我们是视图则是一组可以将任何邮件或邮件碎片转换成XHTML的XQuery库。

在开发过程中我们发现的优势之一是当需要处理的东西是“活的”，即仍然与它的上下文保持联系的时候，一切就变得很简单很顺利。因而，如果我命令一个渲染库说“从这个邮件中将信末署名提取出来。”于是它便遍历树结构来找到相应的时间，发送者，主题，或任何其它想要的信息，它甚至可以通过查询而获知这是否是该邮件发送者最近的签名。当你面对“死的”数据的时候，你就必须给视图逻辑传递它可能需要的所有信息。虽然也行，但是随着时间的演进，你不得不调整你的"握手（handshake）”来适应改变（或者更常见的是视图不处理一些它本可以处理的东西，因为传递给它所需的数据不是件容易的事。）有时候你会遇到这样的情况，有些数据计算起来很昂贵，且视图只是“有些时候”需要这些数据，这时候你会怎么做呢？每次都付出一样的代价？当然不会，你常常会试着倾向于选择性地传递这样的数据。我很高兴现在我们完全不用为这些情况而杞人忧天。

当然，我们选择使用纯XQuery的无可抗拒的基本原因是混合性内容（比如说这里提到的邮件）实在是除了XML以外再没有任何更好的表现方式可替代。所以从模型的角度来说，它非常需要XML。虽然我热爱JDOM，但用它来写处理XML的控制器要比使用XQuery弱很多。当你的模型是XML，视图也产生出XML（XHTML） 的时候，如果你用来编写模型和创建视图的语言也是以XML为中心的就最好不过了。

在搜索过程中，MarkMail提供了非常重要的各种分析视图。究竟是什么推动了目前的视图，对于未来的强化方向又有什么端倪呢?

我们相信人们并不只是想要搜索内容，他们想要的是和内容交互。有时候你想要找到绣针，有时候你想要看整个草垛长什么样子。（注：a needle in a haystack是一个谚语）， 又有时候你只是想要浏览。

我们发现直方图可以帮助人们找到方向感。同时，它也是识别发展趋势及探索所谓“群体智慧”的好助手。

关于某个话题的讨论是向上还是向下发展呢？讨论来来回回反反复复？其中是否能看出某种模式？有一个很有意思的例子，试着查询“javaone”，你会看到峰值出现在每年大会前后的一个月里。你可能想不到，这个话题每年都在增长，2006年最突出。

MarkMail分析的下一步会是什么呢？是与图表交互，新的图表类型，以及新的数据表现方式。我可以十分肯定地告诉大家。

网站运用了大量的Ajax，你们曾经考虑过哪些框架，为什么你们最后选择了现在这一个？

我们也想有一个简单的Ajax构架能满足我们所有需求，给予我们所有想要的widget，将一切简化得就像在公园里散步一样简单惬意。但实际上没有，我们只在底层Ajax交互上使用了MochiKit，除此以外我们几乎自己开发了全套Widget架构。左／右滑栏、修饰的选择框，弹出式缩略图查看器，以及互动的结果列表，全都是我们自己开发的。

在开发中最具挑战性的用户界面功能是什么？

“搜索结果组”和“线程／消息”视图之间切换的左/右滑栏，我们尝试了很多次才得到正确的实现。这是来自于Ryan Grimm 的背景故事，他发明了令左／右滑栏正常工作的“魔法”：

"起初，我试着使用三个div，将它们都设置成float left，这样它们看起来互相紧挨着。原先的打算是随后调整第一个div的左边距，其它的div也随之向左靠拢。结果证明这样的安排在主要的浏览器中很难成功。

所以后来我说忘掉这些精美的CSS布局，试试用表格来布局又如何。一行三列的表格，每个部分一个表格。我本想调整表格的位置，但就在我有这个想法的时候，我认识到我可以将这两个方法结合起来得到一个完整的解决方案。

所以我最终将这三个div置于一个主div中 （该div的id为please，因为我当时真的是希望这个方案能行得通）。然后通过调整“please”div的左边距，终于使得它们三者能够同时滑动。

该滑栏“把戏” 的一个缺点是需要明了在用户重新设置浏览器视窗大小的时候该如何处理。当用户将浏览器视窗变大的时候，我们需要调节一些东西，主要是查询结果div的宽度，防止消息div一声不吱地溜到视图中去。就在这时，我们发觉一些最新的显示器实际上有足够的宽度来完整显示这三个栏目。所以在重新设置大小的时候，我们不断地查看确认用户的视窗是否大到可以同时显示三个栏目。

我并没有调节任何滑栏的可视性，它们都仍然是可视的（只不过在屏幕之外），并且内容的宽度实际上并没有改变。

尽管我们尚未在公开网站上发布，事实上我们还开发了一个甚至于比滑栏更具技术挑战的功能。这是一个新的呈现技术，它能使有多处命中搜索关键字的邮件消息变得更易于阅读。我们更乐意在将它向公众发布之后，对这个技术做更多更详细的介绍。

在你们的日程上，对于新版本的MarkMail有怎样的计划？在为大部分开源邮件列表建档方面，你觉得它会成为GMane或Nabble强力竞争对手吗？

GMane设计的目的是将它作为一个邮件与新闻之间的网关，我向所有想要像查看新闻feed一样查看邮件列表的人们推荐使用GMane。Nabble主要是为人们提供论坛，所以如果你想要的是论坛，那么它是一个很好的选择。

在MarkMail，我们关注于研究、分析以及性能——特别关注于帮助一些组织和团队从他们的历史邮件中获取更多的东西。自启动以来，我们已经载入了两百多万的邮件，并还将继续载入更多邮件列表，我们同时面向开源项目和其他一些项目，目前包括载入和等待载入的邮件已经达到六百万。我们可以根据组织和团队的要求优先载入数据，所以如果你们想要加入你们的列表，请告诉我们http://markmail.org/docs/feedback.xqy。