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

Labs/Jetpack/Reboot/JEP/106 (view source)

Revision as of 19:05, 16 February 2010

2,641 bytes added , 16 February 2010

add discussion section, move my notes off from the wiki "discussion" subpage

Warner

Confirmed users

471

edits

@@ Line 53: / Line 53: @@
 === API Methods ===
+== Discussion ==
+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)