Firefox/Projects/Jetpack: Difference between revisions
m (→Current Status) |
|||
Line 19: | Line 19: | ||
== Current Status == | == Current Status == | ||
<onlyinclude>adw, mossop, ddahl, zpao attending weekly Jetpack meetings. Jetpack team is iterating on the [[Labs/Jetpack/Reboot/JEP|round-one | <onlyinclude>adw, mossop, ddahl, zpao attending weekly Jetpack meetings. Jetpack team is iterating on the [[Labs/Jetpack/Reboot/JEP|reboot's round-one API proposals]]. myk has begun a holistic analysis of them to ensure consistency, general niceness. atul and aza meeting with lucas, security peeps.</onlyinclude> | ||
== Next Steps == | == Next Steps == |
Revision as of 23:49, 11 February 2010
Summary
Make sure Jetpack's needs in Firefox and Platform are met. Implement on trunk support for (re)loadable extensions. Facilitate communication between Firefox and Jetpack teams.
Background
Jetpack's architecture under versions 0.8 and earlier (now called the Jetpack "prototype") is being phased out for a new architecture nicknamed the Jetpack "reboot". Check the Labs reboot wiki page for details, but briefly, the differences between the two:
- "Jetpacks" produced under the reboot are actually XPIs. They're real extensions. Under the prototype they were single JS files.
- Since jetpacks are now extensions, it no longer makes sense to say "I made a jetpack." It's more like, "I made an extension using Jetpack."
- Jetpack itself is no longer an extension. It no longer makes sense to say, "I installed Jetpack."
- The reboot is basically a toolchain, runtime, and API -- a framework.
- "Cuddlefish" is what Atul has coined this framework.
- The reboot is very loosely integrated with Firefox. The runtime is bundled in each XPI. The only significant hook that these XPIs require is a (re)loadable extension mechanism.
- The reboot has a security model, the prototype didn't.
- Roughly speaking, there are two layers of APIs under the reboot. There's a low-level, chrome-privileged layer that wraps the platform. And there's a high-level, secure, low surface area, and friendly layer that builds on the lower. It's the higher layer that might be thought of as "the Jetpack API," but it's entirely possible to use the lower to build an extension.
- The Bespin IDE of the prototype will be replaced with a contracted-out in-browser IDE called "FlightDeck." FlightDeck provides a nice UI to Cuddlefish's toolchain.
Current Status
adw, mossop, ddahl, zpao attending weekly Jetpack meetings. Jetpack team is iterating on the reboot's round-one API proposals. myk has begun a holistic analysis of them to ensure consistency, general niceness. atul and aza meeting with lucas, security peeps.
Next Steps
- Continue to iterate on the API we want under the Jetpack reboot.
- myk will finish his holistic analysis of all the round-one API proposals.
- Planning to finalize those round-one proposals early next week, begin implementation late next week.
- Probably starting next week: A security and Firefox/Platform dependency analysis to find any Firefox/Platform blockers or larger concerns arising from the finalized proposals.
- Separately, mossop will be working on bug 542385, (re)loadable extensions.
Related Bugs
Meta tracking bug for Jetpack dependencies in trunk Firefox/Gecko: bug 543856
Calling out some important ones for Firefox team:
- (Re)loadable extension mechanism: bug 542385. (Branch version is bug 544021.)
Related Links
- Jetpack reboot wiki
- Jetpack team weekly meetings wiki
- #jetpack
- There's a Jetpack drivers mailing list. Ping adw or Daniel Buchner if interested.
Team
- Wiki page writer: adw
- Members: mossop
- Jetpack peeps: atul, myk
Goals
- Implement on trunk support for (re)loadable extensions.
- Make sure Jetpack has what it needs for a smooth uplift into Firefox.
- Keep an open communication channel between the Firefox and Jetpack teams.
Non Goals
- Finalize or dictate the Jetpack APIs.