Labs/Jetpack/Reboot FAQ: Difference between revisions

added sections and a new question
(added another question)
(added sections and a new question)
Line 1: Line 1:
== General ==
'''What's the rationale for this reboot?'''
Check out Atul's blog post entitled [http://www.toolness.com/wp/?p=746 Evolving Firefox Extensions].
'''Why is the Jetpack reboot so much harder to use than the original Jetpack prototype?'''
Our ultimate goal is to make the reboot as easy to develop extensions with and iterate on as the prototype.  Right now, the reboot is essentially the underlying command-line tools that a front-end IDE will use to make things much easier to use.  This front-end IDE will have similar developer ergonomics to the original prototype's interface.  When everything is finished, Jetpack developers will download and install a "Jetpack SDK" that will automatically set up a cfx/jpx environment and the front-end IDE on the developer's computer.
'''Why can't I install, uninstall and upgrade Jetpacks without restarting the browser anymore?'''
Because Jetpacks are currently being built as bootstrapped XPIs that have no dependencies, we're actually building-in the notion of "extensions that know how to unload themselves" into the Mozilla platform itself.  Until we build this into the platform, however, we won't be able to manage Jetpacks without rebooting--even though "under the hood" the Jetpack platform knows how to unload its resources without rebooting.  For more information on this, see [http://www.toolness.com/wp/?p=746#comment-2631 comments on Atul's blog post].
== Packaging ==
'''How do we share/find packages?'''
Right now we need a better solution for this.  One super lightweight solution is to just use a wiki page with a simple format that <tt>cfx</tt> can automatically retrieve and parse.  Narwhal uses github for everything and a <tt>catalog.json</tt> file to index packages.  We could potentially use bitbucket... Or if bitbucket/github have a developer API and some concept of "tagging" projects, we might be able to e.g. just define the available packages as all projects tagged with <tt>#cfx-package</tt> or something.
'''Why doesn't the Jetpack reboot just use narwhal and tusk?'''
Narwhal is an awesome project, but it's just moving too fast right now for us to use it as a dependency.  cfx is similar enough to narwhal/tusk that we might eventually be able to move over to it, and substitute out current Python code for JS.
== Coding ==
'''Note:''' The file capability mentioned below is [http://hg.mozilla.org/users/dwillcoxon_mozilla.com/jetpack-capabilities/ here].  Code is messy.
'''Note:''' The file capability mentioned below is [http://hg.mozilla.org/users/dwillcoxon_mozilla.com/jetpack-capabilities/ here].  Code is messy.


Line 70: Line 96:


Use the [http://wiki.commonjs.org/wiki/Modules/1.0 CommonJS module standard] to separate different kinds of functionality like this.
Use the [http://wiki.commonjs.org/wiki/Modules/1.0 CommonJS module standard] to separate different kinds of functionality like this.
'''How do we share/find packages?'''
Right now we need a better solution for this.  One super lightweight solution is to just use a wiki page with a simple format that <tt>cfx</tt> can automatically retrieve and parse.  Narwhal uses github for everything and a <tt>catalog.json</tt> file to index packages.  We could potentially use bitbucket... Or if bitbucket/github have a developer API and some concept of "tagging" projects, we might be able to e.g. just define the available packages as all projects tagged with <tt>#cfx-package</tt> or something.
'''Why doesn't the Jetpack reboot just use narwhal and tusk?'''
Narwhal is an awesome project, but it's just moving too fast right now for us to use it as a dependency.  cfx is similar enough to narwhal/tusk that we might eventually be able to move over to it, and substitute out current Python code for JS.
'''Why is the Jetpack reboot so much harder to use than the original Jetpack prototype?'''
Our ultimate goal is to make the reboot as easy to develop extensions with and iterate on as the prototype.  Right now, the reboot is essentially the underlying command-line tools that a front-end IDE will use to make things much easier to use.  This front-end IDE will have similar developer ergonomics to the original prototype's interface.  When everything is finished, Jetpack developers will download and install a "Jetpack SDK" that will automatically set up a cfx/jpx environment and the front-end IDE on the developer's computer.
'''Why can't I install, uninstall and upgrade Jetpacks without restarting the browser anymore?'''
Because Jetpacks are currently being built as bootstrapped XPIs that have no dependencies, we're actually building-in the notion of "extensions that know how to unload themselves" into the Mozilla platform itself.  Until we build this into the platform, however, we won't be able to manage Jetpacks without rebooting--even though "under the hood" the Jetpack platform knows how to unload its resources without rebooting.  For more information on this, see [http://www.toolness.com/wp/?p=746#comment-2631 comments on Atul's blog post].
874

edits