StoneAgeDict现阶段设计小结

今天和zy结队编程了一天，讨论了很多问题。主要是围绕词库的开放式、实时的基本特性讨论的。

下面是对这两个特性的基本描述：

What？

1. 开放性

注册用户可以在查询出来的词汇中提交自己的词汇解释。这个解释将被递交到词库审核组，由审核组的工作人员审核这个提交。

例如，用户Daniel查询了beyond这个词汇，但是对这个词有着自己的理解，他可以提交这个理解给审核组。

2. 实时性

当一个新的词汇定义被审核组审核通过后，这个定义将被加入到词库中。

例如，用户Daniel提交了beyond的一个定义，审核组通过了这个提交，则把这个新的定义追加到词库中的beyond词下。

Why？

考虑了词库的权威性，要完全做到开放式很困难，其最困难的地方就是词库的维护。

1. 由用户自己维护自己词库的话容易导致词库内无用的单词过多，甚至是词库的无效

2. 由专门的审核人员审核，工作量大

权衡利弊，我们选择了由专门的审核人员审核的做法。

How？

词库分为两种：

1. 查询词库

由用户提交的查询请求都集中在这个词库中进行查询，如果词库中不存在用户要查找的词汇，则说明词汇未找到。这个词库内的单词是不能重复的。

2. 待审核词库

由用户提交的新词或者是对已有词汇定义的新增 都放入这个词库，等待审核人员的审核。如果审核通过，则将该词加入查询词库：新词直接新建一个词汇记录；对于已有词汇定义的新增附加到该词汇的定义后。

3. 词库的存储

无论是查询词库还是待审核词库都采用数据库存储。经过测试，一个43W词汇的词库，检索一个单词可以在3－4s内完成。如果再建立缓存服务的话，效率可以保证。

XML?!

目前，XML格式的词汇文件作为核心交换文件格式。例如从查询词库中返回的词汇记录，采用XML格式直接传输到Web界面，由Web服务器解析后显示；从 其他词汇网站／服务提供的单词转换成XML格式，并保存进入待审核词库。

实现

1.OSGi Framework

整个应用以OSGi作为底层框架，以 面向服务的组件模型构建。这样可以做到很好的模块化，把耦合降到最低限度，为 将来的扩展打下坚实的基础。

2. 基本查询词库构建

基本的查询词库由 StarDict词库转换而来，测试转换了一个43W词汇的英汉词库，耗时5小时。

3. 查询缓存

由于词汇量很大，做缓存是必须的。不过现阶段还没有做，还处于研究阶段。

Another Idea....

在确定以上方案后，还有一个方案可以选择：
1. 每个用户都有自己的词库，词库中的每个词汇都有一个 得分
2. 查询词汇时从所有用户词库中查询
3. 按词汇 得分大小降序显示各个用户的词汇解释
4. 用户可以对词汇进行 评分
5. 用户可以提交对某个词汇的修改，修改由该词汇的拥有者审核

这个方案是建立在词汇评级以及词汇审核开放的基础上的，有一定的可行性。