Confirmed users, Bureaucrats and Sysops emeriti
1,217
edits
XPCOM Startup: Difference between revisions
Jump to navigation
Jump to search
compatibility
(XPCOM startup draft) |
(compatibility) |
||
| Line 15: | Line 15: | ||
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 significant change in binary compatibility and in some cases source compatibility. NSGetModule and nsIModule would be replaced with a single NSGetClassObject API. It is likely that NS_IMPL_NSGETMODULE would continue to work. I will need to audit the existing module implementations to determine whether module constructor/destructors need to be retained in some form. | |||
== Part B: only libxul components for the content process == | == Part B: only libxul components for the content process == | ||