Confirmed users
396
edits
(compatibility) |
m (Add See also link to XPCOM Shutdown) |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
(Note - this change has landed on mozilla-central! Benjamin helpfully came up with a [[XPCOM_Startup:Changes_for_developers|list of changes you'll need to make to your code]]) | |||
In Firefox 3.x, XPCOM initialization is programmatic, and component registration is a one-time event. This leads to several problems which we'd like to solve for Firefox 4: | In Firefox 3.x, XPCOM initialization is programmatic, and component registration is a one-time event. This leads to several problems which we'd like to solve for Firefox 4: | ||
| Line 16: | Line 18: | ||
Instead of using a programmatic callback (nsIModule.registerSelf), components should export their registration as static data tables. The precise form of these tables is TBD: I'd like to just use chrome.manifest for all the data in extensions, and binary exports for libxul/DLLs. | Instead of using a programmatic callback (nsIModule.registerSelf), components should export their registration as static data tables. The precise form of these tables is TBD: I'd like to just use chrome.manifest for all the data in extensions, and binary exports for libxul/DLLs. | ||
This is a | The category manager would no longer by dynamically mutable, and would use read-only methods. | ||
This is a change in both binary and source compatibility. NSGetModule and nsIModule would be replaced with a single NSGetFactory API. | |||
== Part B: only libxul components for the content process == | == Part B: only libxul components for the content process == | ||
| Line 31: | Line 35: | ||
* query the extension manager and allow it to perform install/upgrade/uninstall tasks | * query the extension manager and allow it to perform install/upgrade/uninstall tasks | ||
* load extension components as necessary | * load extension components as necessary | ||
== See also == | |||
* [[XPCOM Shutdown]] | |||