在新的 Firefox 中，随着我们与之交互的 XPom 界面的变化，我们正在发布越来越多的库。我们有 10 个 dll，并且还在不断增加，每个 dll 的大小接近 2M。
这个尺寸是一些用户关心的问题。
当我们考虑重组库以分离我们可以在它们之间共用的部分时，我们正在考虑如何在支持版本升级的同时减少磁盘空间。
例如，用户安装了 FireFox 3.6 和 4.0，当安装我们的产品时，我们为每个版本安装一个 dll。当 Firefox 升级到 4.0（例如升级到 6.0）时，我们现在如何从 msi 安装缺少的 dll 以支持 6.0。
关于我们如何实现这一目标有什么想法吗？
我们的担心是无缘无故的吗？
我的第一个想法是我们“AllowAdvertise”，当 FF 尝试按照 chrome 的指示加载 dll 时，它会导致安装，但它似乎不起作用。
With the new firefox we are shipping more and more libraries as the XPom interfaces we interact with are changing. We are at 10 dlls and increasing, each with a size of almost 2M.
This size is a concern for some users.
While we look at restructuring the library to seperate the parts we can make common between them, we are thinking about how we might reduce space on the disk while supporting version upgrades.
For instance, user has FireFox 3.6 and 4.0 installed and when our product is installed we install a dll for each version. When Firefox is 4.0 upgraded (say to 6.0) how might we now install from the msi the missing dll for 6.0 support.
Any ideas on how we could achieve this?
Are we worrying for no reason?
My first thought was we 'AllowAdvertise' and when FF tries to load the dll as directed by chrome it will cause the install, it doesn't seem to work.
发布评论
评论（2）
我猜您的扩展仅适用于 Windows，因此支持多个平台不是问题。可能的短期解决方案：
minVersion4.0 和maxVersion4.*） 。%APP_VERSION%非常重要。%APP_VERSION%4.0.1 的更新检查将被发送到extension-ff4.xpi，而%APP_VERSION%6.0 将收到扩展-ff6.xpi。当应用程序更新时，Firefox 将始终检查扩展程序更新。如果您能给它一个兼容的更新，它就会安装它。但是每六周准备一次新的包需要大量的努力，我猜你想尽快重构你的代码/移动到 js-ctypes。哦，我认为您需要忽略某些用户安装了多个 Firefox 版本的不太可能的情况。
I guess that your extension is Windows-only so supporting multiple platforms is not an issue. A possible short-term solution:
minVersion4.0 andmaxVersion4.*).%APP_VERSION%in the URL.%APP_VERSION%4.0.1 would be sent toextension-ff4.xpiwhile%APP_VERSION%6.0 would getextension-ff6.xpi.Firefox will always check for extension updates when the application is updated. If you can give it a compatible update it will install it. But preparing new packages every six weeks requires tons of effort and I guess that you want to refactor your code/move to js-ctypes ASAP. Oh, and I think that you need to ignore the unlikely scenario that some user has more than one Firefox version installed.
我的第一反应是建议您放弃 XPCOM 并转向 js-ctypes。毕竟，这是 Mozilla 正在推动扩展开发人员的方向（请参阅 Wladimir Palant 的评论 例如）。如果您的二进制代码中没有任何内容绝对需要使用 XPCOM，那么您会更乐意提供一个在需要时通过 js-ctypes 与 JS 交互的 DLL。
My first reaction is to suggest that you move away from XPCOM and towards js-ctypes. After all, this is the direction that Mozilla is pushing extension developers (see Wladimir Palant's comments for example). If there isn't anything in your binary code that absolutely positively requires use of XPCOM, you'll be much happier to ship a DLL that interfaces with JS when needed via js-ctypes.