在第一次尝试写插件可惜的失败后，费了一天的功夫，终于写出一个像样的插件。这里面融合了第一次尝试的许多成果。可是还是为了许多细节问题大费周章。比方说（该问题浪费我两小时）：
.properties 必须以#COMMON打头，必须是一种特殊的utf-8格式。这种格式在Windows环境下很难生成。以上描述可能不够准确，可我也不想去细究了。以后有空再说吧。这几句话可使我经过上千次实验才得出的，因为我没有找到任何文档提及到这几点。唉！Mozilla 还有很多地方的改进阿。

我写的这个插件，可以以树状结构浏览RDF文件，可以展示RDF的全部内部结构。现在正交由Mozilla得人审查。

希望Bug不要太多！

为Firefox编写插件很有意思，却又很费力气，因为调试手段太缺乏。

由于Firefox在版本升级中，插件的结构发生了一定变化，而Mozila的文档对这些变化显得很不统一，也造成了一些困扰。以下所有内容，只在Firefox 1.5.*上得到验证。

一个打包好的Firefox插件是一个扩展名为xpi的zip文件，它包括以下几个部分：
1、chrome.manifest
这是核心配置文件，是它指导Firefox内核把插件的各个模块配置并组装起来，安放到指定的位置。

2、install.rdf
这一个安装和卸载是使用的描述文件，包含大量的字符串，主要供Extension Manger获取文字性的描述信息。

3、chrome/your-name.jar
这也是一个zip文件，它将会被chrome.manifest引用。

这个your-name.jar将大部分插件的内容打包，其中又包含三个文件夹
1、content
这个文件夹中包含界面描述文件XUL，JavaScript，以及资源文件。
2、locale
这个文件夹中包含为各地区和语言定制的字符串资源，可供界面文件等引用。它们应使用UTF-8编码。
3、skin
这个文件夹包含CSS样式表，可用来修饰界面文件

Firefox对所有这些文件的要求都很严格，一个细小的错误就会造成整个程序的功能错误。因此，编写时必须十分小心。

怎样具体的实现一个游戏引擎呢？

首先来设计程序的结构。

一般说来，一个J2ME包含一个MIDlet类，一个或多个Canvas类。MIDlet类不包含太多具体功能，只起一个入口点作用（作为内部事件机制的一个接口）。Canvas类实现绝大多数功能，包括绘制用户界面，实现界面逻辑，实现用户逻辑等等，基本囊括了所有东西。对于一个游戏引擎来说，虽然也可以采用这种方法，但由于游戏引擎的复杂程度大，所以这种实现结构太不清晰。首先还是采用经典的MVC方式，将引擎分为三部分：

Canvas类：他继承自GameCanvas类，处理游戏界面的绘制。

Engine类：他处理工作线程的创建和中止，处理虚拟时间的流逝，读取用户输入，并交由其他类处理。他还要处理各类定时器事件。这是最难设计的部分。

Document类：他包含游戏的模型，包含游戏本身的各种功能。他提供一个接口给Canvas类，交由其获取游戏状态；又提供另一个接口给Engine类，供其调用，以处理各种输入和事件。

其实是Moto公司的手机和J2ME模拟器的实现与标准不符。
在J2ME标准中，GameCanvas类的flushGraphic (int x, int y, int w, int h)方法,被定义为:
刷新缓冲区内(x,y,w,h)的矩形区域，到屏幕的对应区域内。缓冲区和屏幕间的像素是一一对应的。
而在Moto公司的实现中，该方法被定义为将缓冲区内(0,0,w,h)内的内容拷贝到屏幕的(x,y,w,h)区域内，与标准存在明显的不同。在标准环境下运行正常的程序在Moto环境下完全无法使用。
以上差异，在SUN的WTK2.2呵Moto的J2ME SDK 5.4及E680i手机上验证确实存在。令人差异的是，Moto的文档竟对此毫无说明！个人认为，Moto的开发技术支持是最差的公司之一。
一种解决方案为，使用translate函数对缓冲区做坐标变换，以实现与标准的相一致。（该方法未验证，仅供参考）

不同的J2ME应用程序采用的是事件驱动模型，采用这种模型作为游戏引擎，需要采用定时器来作为事件输入。它的主要难题在于难于实现各事件间的全局同步，难于实现暂定与恢复。一个成熟的游戏引擎，应该实现以下几个功能：
1、能简化游戏的结构设计，尤其是简化游戏的状态管理
2、能实现开始、结束等各菜单界面
3、能实现随时的暂停和恢复
4、当有电话或其它异步事件发生时，能自动暂停游戏，并可恢复
5、可在游戏中调节游戏选项
6、支持各种游戏类型，包括实时的游戏进程，可自适应调整的人工智能，可处理多种用户输入等。