<item>
<title>The Artist's Way: A Spiritual Path to Higher Creativity - $11.17</title>
<link>http://www.amazon.com/exec/obidos/ASIN/1585421464/lockergnomedigit/?ref=nosim&dev-it=D34HUVGKB34YFX</link>
<description>http://www.lockergnome.com/ </description>
</item>
...
</channel>
IndexRunner -i http://www.example.com/rss.xml -o c:\index -t title,description -n link -l 4
-l 4 表示拿第4层节点作为字段映射，
IndexRunner还提供了-a -m这两个选项：用于增量索引和批量索引优化。
-a 增量索引，表示在原有索引的基础上扩展
-m mergeFactor 在Lucene中mergeFactor是一个针对批量索引的优化参数，控制多少条处理完多少条记录（Document）后，写入一次索引，写入频率越高，内存使用越少，但索引速度越慢，所以在大批量数据导入时需要增大文件写入的间隔，多让索引在内存中操作。
搜索结果输出：
以下是系统设计过程中一些设计的思路：
做为工业标准的XML
记得以前有关于肯德基的炸薯条断顿的报道。从这个事件报道中我们可以看到一种更高效的管理体系：对于快餐店这样全球性的企业来说，要保证各地提供的薯条品质，成本最低的方法肯定是依靠机器而不是厨师，如果要求薯条机能够处理各种形状不一的土豆，机器的复杂程度和维护成本都会很高。所以土豆必须严格符合工业标准才能让结构比较简单的薯条机生产出符合标准的薯条，因此，薯条的加工机械会严格按照土豆协会的土豆工业标准设计。高质量的原料可以大大降低后期加工设备的成本，因此从总体成本上讲还是合算的。
对于软件应用开发者来说：应用和应用之间，企业和企业之间交换的数据好比就是土豆，白菜，按照严格的XML标准设计的接口作为企业之间后台数据交换的工业标准，虽然不如简单的CSV格式高效，但缺能大大简化下游工序的后期加工成本。
不难想象为什么处理HTML的浏览器：IE和Mozilla等浏览器软件大小都在10M以上，但一般处理XML的解析器一般都在几百K。除了没有界面外，HTML浏览器需要为太多不规范的HTML代码提供大量容错处理也是一个很重要的原因，而语法严格，规则简单的XML处理器就可以做的很简短，高效，体积越“小”就意味着适应性越广：这点在手机这样的硬件配置比较低的设备环境中显得尤其重要。
虽然XML在后台数据交换方面，有着巨大的潜力。在前台表现方面，XML并不会马上代替HTML，很多通过XSLT输出的HTML仍然需要结合CSS来进行表现。XML ==XSLT==> HTML + CSS。但是由于太多的网页都是用HTML做的，相信XML没有必要马上代替这些已有的机制。
此外在应用的国际化支持方面XML和Java简直是绝配：XML数据源用Java解析后是UNICODE，这样无论是日文，繁体中文还是德文的内容我们都可以在一个索引库中同时进行搜索。这样针对其他语言的支持只是设计各种语言界面的问题了。
GBK \ / BIG5 BIG5 - UNICODE ====> Unicode - GB2312 SJIS - (XML) (XML) - SJIS ISO-8859-1 / \ ISO-8859-1
上一篇:让Windows文件无法删除提示从此不再出现
下一篇:Google欲推容量无限的网络存储服务
|
精品推荐