XPCOM指南_7结束编写WebLock.docVIP

现在您已创建组件的大多数基础结构。 该组件可以被XPCOM和类别管理器识别，那样在 XPCOM初始化时，它就可以开启动。 组件启动时，它会读取存储在本地文件系统里Url列表，填充到相应的二进制结构。 Using Frozen Interfaces 然而，现在阻止站点的核心功能仍然缺失。 这个接口仍然没有冻结，组件开发人员需要讨论那些功能应该完全公开，所以API没有准备好发布。 这让你处于和大多数使用Mozilla的开发者一样的境地—你想使用一些特定的功能，但是接口似乎天天都在变。 所有的Mozilla的源代码是公开的，并且接口使用也很容易。 抓一个合适的头文件，使用组件或者服务管理器访问你需要的接口和XPCOM对象，实现你将会在你的项目里实现的接口。 这带来了很大的灵活性，当然你会失去一些兼容性。 如果你使用没有冻结的“东西”，那个东西将来可能随着Gecko的版本变化而变化。 如果你想你的组件能够对来自Gecko的变化免疫，你必须只使用已经冻结的接口和APIs。 一般这会在接口申明上面的进行说明。 例如，下面的nsIServiceManager： /** * The nsIServiceManager manager interface provides a means to obtain * global services in an application. The service manager depends * on the repository to find and instantiate factories to obtain * services. * * Users of the service manager must first obtain a pointer to the * global service manager by calling NS_GetServiceManager. After that, * they can request specific services by calling GetService. * When they are finished they can NS_RELEASE() the service as usual. * * A user of a service may keep references to particular services * indefinitely and only must call Release when it shuts down. * * @status FROZEN */ 冻结的接口和函数时GECKO SDK的一部分。 有一个经验，SDK外部的接口可当作是“实验性”的或者未冻结的。 参见侧边拦的信息，它描述了冻结或未冻结的接口怎么影响你的软件开发，它还包括了接口变化会导致严重破坏的一些技术细节。 使用未冻结接口的危险性 假设你在您的组件里使用了未冻结的接口，nsIFoo，这个接口在你测试时使用的那个版本的Gecko很正常。 然而在将来某个时候，nsIFoo有了重大变化，它的方法重新排序，添加，删除了一些。 此外，这个接口不应???被其它的Gecko或Mozilla客户使用，接口的维护人员也不知道有其它的开发者使用了这个接口，他并不会改变接口的IID。 当你的组件在此新版本的Gecko里运行时，你的方法调用将会通过不是你期望的虚表（v-table）路由，这将会产生一个不可预期的结果，甚至导致崩溃。 看下面的图，组件编译时使用的nsIFoo接口有三个方法。 组件调用TestA方法，传入一个整数10。 这个可以在任何如编译时使用的相同版本的Gecko的应用上正常运行。 然而当nsIFoo接口发生了变化，TestA方法被删除了；虚表里的第一个函数现在成为了IsPrime()。 当组件调用TestA时，实际上它是调用的方法IsPrime。 不用说，这很不爽。 此外，还没有一种方式，容易的方式来发现这种类型的运行时错误。 Gecko的开发人员可以更改该接口的IID，和一些其它工作。这可以防止很多类似错误。但未冻结的接口不提供任何正式方式支持，和为接口的任何变化提供不同的IID接口并不是一个好主意。 当使用冻结的接口，你就不用担心以后Gecko版本变化会带来兼容性问题。 唯一的问题是，编译器的变化，导致虚表的布局的变化，这种变化只在编译器的ABI变化是会发生。 例如，2002年的GCC 3.2改变了C++的ABI，这将会影响所有用GCC3.2编译的应用程序。 相应的问题在GCC 4.0时也发生过。 在你使用未冻结的接口之前，你应该联系负责你使用的代码的开发者，问问他。 他们可能会建议你是否使用这