|
|
| Line 1: |
Line 1: |
| My thoughts (developed during a discussion with Atul last week):
| | |
| * A "jetpack ID" should be the hash of a public verifying key. "jpx create-new-addon" will create a keypair, store the private signing key under ~/.jetpack/, and create a new skeleton add-on directory (with the public key and a manifest, and maybe a hello-world sample).
| |
| * There will be a "jpx publish" command which bundles the various files together, signs the bundle, and drops the signed result in a well-known place, perhaps with an option to upload it to AMO
| |
| * The main purpose of the signed bundle is to convince the add-on manager/loader to grant the new code the same authorities that were granted to its predecessor. In particular, any data stored by one version of an add-on should be available to the update too.
| |
| * A well-known subdirectory of the add-on, perhaps ADDONBASE/resources/, should be used for "bundled resources". These are copied verbatim into the addon bundle.
| |
| * Content frames (as described in JEP-115) should have easy access to bundled resources. In particular, creating such a frame with a URL of "/panel.html" should populate the frame with the contents of ADDONBASE/resources/panel.html , and relative URLs inside it should reference bundled resources too.
| |
| * There should be a simple call that lets add-on code access the contents of bundled resources (from code, as opposed to from HTML), like:
| |
| var resources = require("bundled-resources");
| |
| var data = resources.load("panel.html")
| |
| * These bundled resources are, in general, *not* available from outside the add-on. However, I think it could be useful to add a "publish" feature, such that an add-on could do something like:
| |
| var publisher = require("publisher");
| |
| publisher.publish("/foo.txt", function (req) { return "foo!" });
| |
| and then the rest of the browser could do a GET of <tt>jetpack://id/$JETPACKID/foo.txt</tt> and be given "foo!". The use of $JETPACKID here would be unforgeable.
| |
| * When an exception occurs and we need put a "filename" property onto the exception object, we can use <tt>jetpack://$JETPACKID/jsfilename</tt> for debugging purposes. It would not necessarily be possible to paste this into the addressbar and see the source code in question, though (this sounds useful, but I think it's also important to allow add-ons to keep their resources private, so maybe only allow this to work in a debug console of some sort). It might be best for these URLs to have a different protocol, maybe <tt>jetpack-exception://</tt>, to distinguish it from the URLs managed by the "publisher" feature.
| |
| --[[User:Warner|Brian Warner]] 06:28, 16 February 2010 (UTC)
| |