Overview
Extensions should be able to depend on other extensions. For 1.8, this can simply be the EM refusing to enable an extension until another extension is installed+enabled. In 1.9 timeframe it would be good to ask UMO to help resolve extension dependencies for semi-automatic download and install.
For bonus points, when an extension specifies a dependency it should be able to provide a download link + extension title, not just the extension ID.
Proposed install manifest format
<em:requires>
<Description>
<em:id>extension@somewhere.org</em:id>
<em:name>Some Other Extension</em:name>
<em:homepageURL>http://somewhere.org/</em:homepageURL>
<em:xpiURL>http://somewhere.org/someotherExt.xpi</em:xpiURL>
<em:updateURL>http://somewhere.org/someotherUpdate.rdf</em:homepageURL>
<em:minVersion>0.3.1</em:minVersion>
<em:maxVersion>0.8.9</em:maxVersion>
</Description>
</em:requires>
Notes
When an extension is disabled by not meeting em:requires requirements the extension should be disabled by a new property rather than the disabled property (e.g. autoDisabled or appDisabled). This will make it possible to automatically enable an extension that in the future meets its em:requires requirements without enabling it when it was manually disabled. See bug 264750 for an example and this new property could also be used in that scenario.
Extension Installation
With the additional methods available for installing extensions there are several new paths that have to be considered for handling extension dependencies.
Extension Manager Installation
After all of the installs in progress complete if an em:requires requirements are not met the extension would have the autoDisabled property set and a dialog would be opened to notify the user that the extension(s) require additional extensions to be installed. If the em:requires provides a homepageURL the user would be provided with a link to the required extension's home page. If the em:requires has an xpiURL or updateURL the user would be given the option of installing the required extension.
Thoughts
Q: Should there be both an em:xpiURL and an em:updateURL? The em:xpiURL is simplest but the em:updateURL would provide a more flexible solution in that the em:updateURL could provide xpiURL's for multiple versions. Also, using updateURL could provide integration with UMO with little to no modification of the services provided by UMO and extension authors could use the updateURL in the required extension with the caveat that it may change at the required extension author's discretion.
A: There is no need for xpiURL, let's just stick with updateURL (reduces complexity and the testing matrix).
Startup Installation or Registration
This applies to dropped in files, dropped in directories, registry, etc. TBD - extensions that do not meet their em:requires requirements may just have to be disabled if installed using these methods.
Extension Management
Application Startup
After all operations (e.g. needs-install, needs-upgrade, etc.) are completed during startup enumerate all enabled extensions. For an extension with an em:requires verify all required extensions are installed and enabled and if not set the autoDisabled property of the extension.
Thoughts
Q: Should the user be given a choice in the dialog of uninstalling an extension that requires an additional install?
A: That is not necessary.
Q: Just as the minVersion and maxVersion for application compatibility is automatically updated via the rdf specified in the extension's updateURL the minVersion and maxVersion for an em:requires should also be updated automatically. Also, does return the update rdf if the extension is already up to date?
Q: When an extension is updated it should also take into account new em:requires.
Q: When an extension is updated what should be done with extensions that are no longer required? For example, if after upgrading an extension it no longer requires jslib and it was the only extension requiring it should there be an indication of this to the user and if so what? A: At this point we should not uninstall anything unless the user specifically requests it.
Q: How should circular requirements be handled if at all? A: For the 1.8 cycle circular dependencies are not a requirement; we can safely ignore them.
User Interface
Items that are disabled due to not meeting their em:requires requirements would for the most part have the same available commands as an incompatible item. They would also have the option to bring up the dialog used during install for installing the extensions specified in em:requires that are currently not installed on the system.
Thoughts
If an em:requires extension is updated to a version that is higher than the maxVersion the extension that required it specified then the extension that required it would become disabled.
Q: Should the user be notified prior to updating that updating "required extension" will disable the extension that requires it? A: This would be nice, yes. But if it doesn't make the initial bug, I don't care all that much.
Q: Should there be new user interface for disabling extension updates on individual extensions? A: Possibly, but this is a low priority.
Work is happening in bug 298497