|
|
| Line 1: |
Line 1: |
| <pre class="brush:html;">
| |
| // Jetpack authors can bundle their Jetpack in a .zip file, in which case
| |
| // the manifest can be placed in a manifest.json file. Alternatively,
| |
| // the Jetpack can be a single script that begins with a call to
| |
| // jetpack.manifest.set().
| |
|
| |
|
| jetpack.manifest.set({
| |
| author: "Atul Varma",
| |
| capabilities: {
| |
| // Note that these capabilities are in addition to any
| |
| // capabilities we infer from static analysis of the Jetpack code.
| |
|
| |
| // Third-party capabilities actually import functionality from
| |
| // chrome-space (i.e., the Mozilla platform) to the jetpack.
| |
| // They generally add things to the 'jetpack' namespace.
| |
| thirdParty: ["http://foo.com/http-listener.zip"],
| |
| network: {domains: ["toolness.com"]},
| |
| },
| |
|
| |
| // These are URLS to CommonJS modules or archives of CommonJS modules.
| |
| // They are all given the same privileges as the Jetpack, and have
| |
| // access to the same jetpack.* namespace.
| |
| libraries: ["http://bar.com/blargy.zip",
| |
| "http://bar.com/jquery.js"],
| |
|
| |
| // Boosters are "sub-Jetpacks" that the Jetpack may communicate with
| |
| // via a postMessage-like interface. They get their own sandbox and
| |
| // have their own capabilities. They're accessible via
| |
| // jetpack.boosters.<name>. Unlike the main Jetpack, no
| |
| // capability inference is performed on them, so the capabilities
| |
| // specified in this manifest are the only ones they get.
| |
| boosters: {
| |
| blah: {url: "http://toolness.com/md5.js",
| |
| // Don't give it any capabilities!
| |
| capabilities: {}}
| |
| }
| |
| });
| |
| </pre>
| |