Talk:Labs/Jetpack/Reboot/JEP/106: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(add my thoughts)
 
(moved discussion into bottom section of main page)
 
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)

Latest revision as of 19:06, 16 February 2010

Retrieved from "https://wiki.mozilla.org/index.php?title=Talk:Labs/Jetpack/Reboot/JEP/106&oldid=202587"