Labs/Jetpack/JEP/29: Difference between revisions

Jump to navigation Jump to search
added implementation notes for extenders
(→‎Sample Code: added notes about why extenders, libs, and boosters are specified separately)
(added implementation notes for extenders)
Line 44: Line 44:


Alternatively, if the manifest specifies that the Jetpack only needs to communicate with foo.com, then <tt>XMLHttpRequest</tt> will be injected but attenuated such that connections to domains other than foo.com will fail.
Alternatively, if the manifest specifies that the Jetpack only needs to communicate with foo.com, then <tt>XMLHttpRequest</tt> will be injected but attenuated such that connections to domains other than foo.com will fail.
=== Extenders ===
Extenders are like Jetpack's version of "native libraries": like
traditional XULRunner extensions, they have full access to the Mozilla
platform and its accompanying technologies such as XPCOM and XUL, but
they are entrusted to expose a small subset of it to the importing
Jetpack via dependency injection, perhaps attenuating it as per manifest metadata. This is useful for e.g. traditional addon developers who want to convert their extension to a Jetpack, but require a feature or two that the Jetpack platform doesn't yet provide.


=== Libraries ===
=== Libraries ===
Line 65: Line 57:
As per the CommonJS standard, a SecurableModule can be loaded via a
As per the CommonJS standard, a SecurableModule can be loaded via a
call to the global <tt>require()</tt> function.
call to the global <tt>require()</tt> function.
=== Extenders ===
Extenders are like Jetpack's version of "native libraries": like
traditional XULRunner extensions, they have full access to the Mozilla
platform and its accompanying technologies such as XPCOM and XUL, but
they are entrusted to expose a small subset of it to the importing
Jetpack via dependency injection, perhaps attenuating it as per manifest metadata. This is useful for e.g. traditional addon developers who want to convert their extension to a Jetpack, but require a feature or two that the Jetpack platform doesn't yet provide.
'''Implementation Notes'''
An Extender is actually implemented using a SecurableModule with a system principal that defines a standard function or class on its <tt>exports</tt> object.  This function or class is responsible for injecting its functionality into a Jetpack.  The Extender module runs inside a Cuddlefish runtime (see [[Labs/Jetpack/JEP/28|JEP 28]]), and as such, the Extender is free to use other privileged SecurableModules provided either by Cuddlefish, itself, or another third party.


=== Code Signing ===
=== Code Signing ===
874

edits

Navigation menu