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. 用户可以提交对某个词汇的修改，修改由该词汇的拥有者审核

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