最近在使用 cpp 做 xmlrpc 相关的内容，顺便看了一下几个 xmlrpc 的实现，连带看了一下 expat 的实现。
发现 expat 的接口非常的精简，不过实现的代码比较长，比较难读。
看完之后，有空的时候就在思考有什么办法可以简化 xml parser 的实现。
想了几天之后，想到一个方法：expat 里面有很多的 switch case 结构，要简化这些 switch ，最好使用 state pattern 。

具体的想法如下：
<<1>> 设计一个 XmlReader 类，作为 state pattern 中的 State 类。
XmlReader 的多个子类作为 state pattern 的 ConcreteState 类，
每个 reader 代表 xml parser 的一个状态。
比如有：XmlDocDeclReader，XmlStartTagReader，XmlEndTagReader，XmlCDataReader，
XmlCommentReader，XmlDocTypeReader等等。
<<2>> xml parser 本身作为 state pattern 中的 Context 类。

这样设计的好处（为描述方便，称这个 xml parser 为 spxml）：
<<1>> 每个 XmlReader 识别特定的开始符和结束符，把属于它自己的字符保存下来。
在遇到它的结束符之后，设置 spxml 的后继 XmlReader。
<<2>> 每个 XmlReader 在读取到结束符之后，把保存下来的字符串转换成 parser 相应的事件。
比如：对于 XmlStartTagReader 来说，如果是一个 pull-model 的 xml parser，
将产生一个 START_TAG event；如果是一个 sax-model 的 xml parser，那么将产生
StartElement event。
<<3>> 这样把 xml 的各个部分的处理分散到了不同的类里面，每个类只处理一类情况，
这就使得 spxml 的实现从整体上简化了。
<<4>> spxml 像 expat 一样，是一个面向流的解释器。
使用者可以把任意大小的 xml 片断（从一个字节到完整的 xml document）传递给 spxml 进行解释。
expat 需要由使用者指出 xml document 何时结束；相反，spxml 不需要由调用者指定 xml document
何时结束，在解释完 root element 之后，spxml 将返回 END_DOCUMENT 事件。
因此 spxml 适合使用在类似 jabber 这类协议的通讯中。
因为 jabber 的传输协议中，任意两个请求包中是没有明显的分隔符的，每个请求只是一个完整的 xml element。

为了验证一下自己的想法，趁这段时间休假，花了几天时间实现了一下，初步看起来还是不错的。目前针对简单的 xml 实现了 xml pull parser 和 xml dom parser，足够用来处理 xmlrpc。

具体的实现可以参考：http://code.google.com/p/spxml/
http://spxml.googlecode.com/files/spxml-0.2.src.tar.gz

对 spxml 和 expat 做了一下性能测试。
以 http://xmlbench.sourceforge.net/ 作为测试框架。

测试环境是在 vmware 上，并且机器性能不好，只能测试 4k 和 256k 的样本。

由于 spxml 没有 sax 接口，而 expat 只有 sax 接口，所以无法直接进行对比，只能借助 Sablot ，双方对 dom 进行测试。

采用的版本：expat-2.0.0 + Sablot-1.0.3

--->Running <expat-sablotron-dom> benchmarks:
-> xmlgen 4 KB
Initialisation time 0.106 + 0.613(6.48%) ms, Parsing Time 1.620(2.45%) ms
-> xmlgen 256 KB
Initialisation time 0.137 + 1.121(114.60%) ms, Parsing Time 126.102(1.02%) ms

--->Running <spxml-dom> benchmarks:
-> xmlgen 4 KB
Initialisation time 0.002 + 0.388(16.89%) ms, Parsing Time 1.601(4.09%) ms
-> xmlgen 256 KB
Initialisation time 0.002 + 5.474(30.01%) ms, Parsing Time 164.281(1.00%) ms