转载：http://zhxiong.bokee.com/3857888.html
应用Mozilla框架的感受
关键词： Firefox ?? Mozilla ?? 社区 ?? ??????????????????????????????????????
?
Firefox 1.5已经正式发布了，Firefox热还在持续升温。浏览Mozilla网站，发现除了各种插件、扩展以外，Mozilla文档整理、平台开发比起两年前真是不可同日而语，想来这些变化和Firefox所引发的关注应该也不无关系。
是的，Mozilla不仅仅是一个浏览器，她是一个平台，一个客户端应用框架――Client Application Framework――许许多多的人在认识了Firefox之后，接着认识到了这一点，这是一件令人高兴的事情。更令人高兴的是越来越多的人，包括中国人，开始为Firefox写扩展、做皮肤，甚至是完全基于Mozilla的应用。看来我们有理由相信，除了Firefox之外，将来Mozilla技术将带给我们更多的惊喜。
我开始接触Mozilla Application Framework也已经近三年的时间，缘于公司技术总监选择Mozilla做为我们一个软件产品的开发平台，大概是Mozilla 1.4发布的时候吧。我们做的是一个运行在用户桌面的应用支撑前台，希望能够在宽带运营支撑系统中起到一个“软终端”的作用，促进宽带增值业务的开展。
我们当时选择Mozilla作为开发平台的理由是：
1. 跨平台
Netscape多年的积累以及后来开源社区的长期努力，导致nspr这样的封装库，对应用系统上层屏蔽平台的差异，使得源代码可以Write once , compile anywhere。虽然迄今为止，我们没有在Windows以外的平台上发布过版本，而且不得已加入了很多Windows的特性，但是由于有做政府项目的初衷，因此这个理由应该还算很充分的吧。
2. 增量升级功能
因为我们做的是客户端应用，C/S模式，客户端应用能充分发挥客户机的计算能力，但是和B/S模式相比的一大问题就是前端的安装、维护和升级成本高。Mozilla框架下的XPInstall提供了强大的在线升级功能，支持升级脚本、支持模块化、增量式安装，很好地解决了这个问题。
3. 动态可扩展的组件模型XPCOM
这是一个Application Level COM Model，提供了组件工厂、自注册、服务、智能指针等基础机制，简单实用，能把系统功能独立于业务流程，很完美地组织起来，实现二进制级的复用。基于XPCOM，能够实现比较灵活的体系结构，这是做应用支撑系统的基本要求之一。
4. 快速的界面开发技术XUL
内置引擎Gecko，不但提供了强大的展现能力，而且提供了简单高效的开发语言（javascript+xul+CSS+XBL+RDF+...），使得做客户端界面和做浏览器页面非常类似，一个具有DHTML或者Java AWK/SWing开发经验的开发人员，经有限的指导下，大约一个月的时间，就可以做出非常复杂的界面。在windows平台上，我们通过Hook方法，还实现了不规则窗口、镂空界面这样的实现效果。
由xpcom提供基础组件，javascript负责动态界面以及业务逻辑的实现，这是对脚本语言、高级语言的善用和妙用。我看过某Mozilla大拿那篇文章《同种羽毛的鸟》，感觉XUL的确影响了未来界面展现技术的发展。
最后，我个人认为是最重要的一点，就是这些优良的机制都在同一个框架之下提供，他们之间结合得非常好，算是一个接近于“无缝”的客户端技术解决方案。
我们在开发的过程中的烦恼是：
1. 学习曲线陡，不容易招聘到“现成”的开发人员
特别是Mozilla平台部分。而且我们还对Mozilla框架做了一些裁减和重组。这需要一个很熟悉Mozilla的人“坐镇”，而且很不容易招聘到这样的人。要成长为这样一个人，即使具备很好的技术素养，也需要长时间的钻研。
上层应用的开发人员（做chrome）也不容易招聘到现成的。虽然这对开发人员技术素养要求不是很高，但是因为平台比较庞大、缺乏开发工具等原因，入门需要一个月以上，因此人员的流动还是会对开发产生大的影响。
文档方面，两年前Mozilla的文档组织还不够好，现在，特别是firefox一炮打红以后， 国内参与Mozilla开源活动的人明显增多，Mozilla文档组织也越来越好，但是对于应用级别的快速开发来说，还是不够的。
2. 缺乏快速开发工具，跟踪调试困难
Mozilla对于chrome开发，主要提供了两个工具，DOMInspector和Venkman，前者用于调试界面布局，后者用于调试Javascript，但是他们互不相关，远非对于应用开发来说比较重要的Rapid IDE。 mozdev上有几个项目做这个，像XULMaker等，但是还很不好用，而且项目进展极其缓慢。因为是在Windows平台上开发，因此我们可以用Visual Studio调试XPCOM，而对于xul和javascript，基本上只能靠“试”了。
3. Mozilla技术具有一定的封闭性
因为要跨平台，因此要自建平台，实际上我们可以认为nspr是一个平台。跨平台的同时必然多少导致与其他技术对接的困难。例如在windows平台上，很多应用都是通过MS COM提供的，我们不得已做了一个MS COM的封装功能，在编译时封装为XPCOM来调用。
我个人认为Mozilla更大的价值，在于平台的框架性。目前为止还没有一个客户端的应用框架技术在稳定性、完整性上能出Mozilla之右吧？开源社区的更大意义，不在于目前有什么，而在于是不是有很多的开发人员参与进来，能够持续不断地创造出新的东西。Firefox已经引起了足够多的注意力，我想Mozilla社区今后应该重点关注在社区开发人员的培养上。具体上要重视这么几个事情：
(1) Mozilla框架技术
Mozilla要有志于提供最完美的客户端应用框架。要改善跨平台层，提供更多的特性；优化内核，提高速度，减少资源占用；完善插件、扩展的机制，为扩展功能的开发提供更多的便利 ... ...
(2) 快速开发工具
诚然，Mozilla的今天离不开一代一代的hacker们的高超技艺，但是离开了应用任何平台都会失去价值。而能够提供应用的，是成千上万的“水平一般”的开发人员。Mozilla应该把手头的几种技术好好地组织一下，做出几个好用的快速开发工具，这是培养应用开发人员最有效的手段。微软的VC，Borland的Delphi、开源的Eclipse、...都是活生生的例子。
（3）文档
应该多一些像《Creating Application with Mozilla》、《Rapid development with Mozilla》和《Javascript Core》这样的书。可能很多唯代码论的人不屑一顾，但是有效的文档至少能大大缩短读代码的时间，对于开发一般应用的参与者是非常有用的。
三年来和Mozilla的“亲密接触”，没有为我所在的公司摆脱困境（根本原因并非技术问题），但是至少做了一次有益的尝试，培养了一些了解Mozilla的开发人员。我虽然换了工作，在新的公司不会基于Mozilla做什么东西，但是我想我还是会持续地关注Mozilla，积极参加到力所能及的开发中去。