Jetpack/Roadmap-2011: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(add milestone markers to chart; simplify versions; revise prototype/extension language slightly)
m (moved Jetpack/Roadmap to Jetpack/Roadmap-2011: archiving)
 
(38 intermediate revisions by 9 users not shown)
Line 1: Line 1:
{{draft}}  
<section begin=summary />{{RoadmapSummary
|icon=Jetpackicon.png
|pagelocation=Labs/Jetpack/Roadmap
|pagetitle=Jetpack 2011 Roadmap
|owner=David Mason
|updated=July 2011
|status=Draft
|description=The top three 2011/2012 priorities for Jetpack are: 1) Enable jetpack to always create add-ons that take advantage of the Electrolysis (e10s) to run in a separate process. 2) Create a path for developers using the traditional tools to move to jetpack. 3) Support Firefox Mobile.}}<section end=summary />


= <b>High-Level Product Roadmap</b> =
{{draft|}}


Jetpack development comprises numerous releases of multiple products that achieve four major milestones. The following chart summarizes the milestones, while the text below it describes them in more detail.
= Top Priorities =


<table border="1" bgcolor="#ffffff">
Building upon a very solid 1.0 release in which we met the highest priorities of shipping a great platform with great docs, and outreach, we now need to turn our attention to extending and improving this platform to make it even easier and open it up to even more capabilities and technologies.
  <tr style="vertical-align: baseline;">
    <th></th>
    <th style="text-align: left; background-color: #9f9f9f;">Milestone One</th>
    <th style="text-align: left; background-color: #cfcfcf;">Milestone Two</th>
    <th style="text-align: left;">Milestone Three</th>
    <th style="text-align: left;">Milestone Four</th>
  </tr>


  <tr style="vertical-align: baseline;">
To that end, our top priorities for 2011/2012 are:
    <th></th>
    <th style="text-align: left; background-color: #9f9f9f;">Jetpack Prototype, Firefox 3.5</th>
    <th style="text-align: left; background-color: #cfcfcf;">Jetpack SDK 0.1, Firefox 3.6</th>
    <th style="text-align: left;">Jetpack SDK (1.0?), Firefox (3.6.x? 3.7?)</th>
    <th style="text-align: left;">Firefox (4.0?)</th>
  </tr>


  <tr style="vertical-align: baseline;">
1) [[Features/Jetpack/SDK_Support_for_Firefox_for_Mobile_Addons | ''Support Firefox Mobile.'']] As we now all understand, the web experience is moving towards smaller devices, we have to make sure that any developer creating an add-on via Jetpack will find that their add-on just works in mobile. Mozilla cares as much about user choice and personalization on mobile devices as it does on the desktop, Jetpack must reflect that with no work from end-user developers.
    <th></th>
    <th style="text-align: left; background-color: #9f9f9f;">DONE, 2009 Q4</th>
    <th style="text-align: left; background-color: #cfcfcf;">IN PROGRESS, ETA 2010 Q1</th>
    <th style="text-align: left;">ETA 2010 Q3/4</th>
    <th style="text-align: left;">ETA 2010 Q1/2</th>
  </tr>


  <tr style="vertical-align: baseline;">
2) [[Features/Jetpack/Out-of-Process_Addons | ''Enable jetpack to always create add-ons that take advantage of the Electrolysis (e10s) to run in a separate process.'']] Running an add-on in a separate process is important for users and the add-on developer as it makes it much easier to determine if an add-on is affecting the browser's performance. In addition, there may be some security enhancement as its much harder to exploit a vulnerability if its being run in a separate process. For Jetpack, we want to ensure that our users never even have to think about e10s or how to use it for their add-ons to run in a separate process.
    <th style="text-align: right;">Firefox</th>
    <td style="background-color: #9f9f9f;"></td>
    <td style="background-color: #cfcfcf;"></td>
    <td>Extension Manager no-restart API, transparent content iframes</td>
    <td>support for Jetpack-native packages, Jetpack library in core?</td>
  </tr>


  <tr style="vertical-align: baseline;">
3) [[Features/Jetpack/Add-on_SDK_Localization_API_and_Service | ''Add-on Localization API and Service.'']] Its important that Jetpack no longer lingers behind in the the world-wide reach Mozilla has worked hard to obtain. We must have a localization solution that allows our developers to get localized add-ons with minimal effort on their part. Addon localization in the SDK comprises a simple, high-level API for specifying the strings to localize, a localization service to which addons distributed by AMO are automatically submitted for localization, a web application through which localizers can localize addons, and automatic repackaging of AMO-distributed addons with new and updated localizations.
    <th style="text-align: right;">Platform</th>
    <td style="background-color: #9f9f9f;"></td>
    <td style="background-color: #cfcfcf;"></td>
    <td>chrome object wrappers</td>
    <td>ECMAScript 5?</td>
  </tr>


  <tr style="vertical-align: baseline;">
= Secondary Priorities =
    <th style="text-align: right;">AMO</th>
    <td style="background-color: #9f9f9f;"></td>
    <td style="background-color: #cfcfcf;">stats on Jetpack-built extensions</td>
    <td></td>
    <td>support for Jetpack-native packages</td>
  </tr>


  <tr style="vertical-align: baseline;">
1) [[Features/Jetpack/Traditional_Addon_Conversion_to_SDK_Platform | ''Create a path for developers using the traditional tools to move to jetpack.'']] If we are successful in bringing in new developers to creating add-ons for Firefox, we must not forget the developers who have been using the traditional toolset. With the inclusion of features such as e10s and mobile, it becomes imperative that we offer the easiest methods possible to create add-ons that work with these new technologies and platforms. We see Jetpack as being a great path for our current add-on developers to start taking advantage of these new features - as long as we can make the porting equally simple. This work includes creating tools which will automatically help developers port their existing add-ons, as well as a good set of documentation and examples to help them understand the differences in approach.
    <th style="text-align: right;">Security</th>
    <td style="background-color: #9f9f9f;"></td>
    <td style="background-color: #cfcfcf;"></td>
    <td>reduced-privilege security model</td>
    <td>ES5-based API hardening?</td>
  </tr>


  <tr style="vertical-align: baseline;">
2) [[Features/Jetpack/Simplify_the_Add-on_SDK | ''Simplify the Add-on SDK.'']] While Jetpack is a simple development tool to use as compared to the traditional add-ons tools Mozilla has offered, we have to recognize that simplicity opens the door for more participation. With more participation comes a greater democracy of ideas and implementations - all of which can benefit the open web. Simplifying Jetpack even more is a high priority because it is one and the same with Mozilla's mission. The steps we can take to simplify Jetpack are:
    <th style="text-align: right;">L10N</th>
    <td style="background-color: #9f9f9f;"></td>
    <td style="background-color: #cfcfcf;"></td>
    <td>Jetpack-native APIs/tools, web service?</td>
    <td></td>
  </tr>


  <tr style="vertical-align: baseline;">
* merge bootstrap.js and components/harness.js, dropping attempts at ff3.6/gecko1 compatibility
    <th style="text-align: right;">API</th>
* merge cuddlefish.js and securable-module.js, breaking code that does require("cuddlefish") for other purposes (sub-loaders? control over loading process?)
    <td style="background-color: #9f9f9f;">prototypes of various APIs</td>
* build a XPI for 'cfx run' and 'cfx test' too, reducing the number of supported code paths from two to one
    <td style="background-color: #cfcfcf;">model for API design</td>
* enable the main addon code and the addon's own HTML pages to communicate directly with each other (rather than having to communicate though a content script)
    <td>robust library satisfying common use cases</td>
* remove package abstraction for SDK's own APIs, moving their code to top-level lib/, doc/, and test/ directories
    <td>stable (frozen?) library</td>
* support putting all addon files into a single top-level directory for simple addons that don't have enough files to justify breaking them up into data/, lib/, and test/ subdirectories
  </tr>
* resolve relative and root-relative text strings passed to URL parameters relative to the location of the script and top-level addon directory for all URL parameters, respectively, so addons can specify "/data/foo.txt" in place of require("self").data.url("foo.txt")
* require in content scripts?


  <tr style="vertical-align: baseline;">
3) [[Features/Jetpack/Add-on_SDK:_the_Missing_Pieces | ''Add-on SDK: The missing pieces.'']] There are several notable Firefox features we do not yet support. These would be simple APIs to offer support for:
    <th style="text-align: right;">Dev Tools</th>
* Prefs API
    <td style="background-color: #9f9f9f;">Bespin-based editor in extension</td>
* Sidebar API
    <td style="background-color: #cfcfcf;">command line</td>
* Add-on Tab API
    <td>FlightDeck web-based IDE</td>
* Tab Groups API
    <td></td>
* minimal XPIs
  </tr>
* packed XPIs
* addon testing without browser restart


  <tr style="vertical-align: baseline;">
4) [[Features/Jetpack/Add-on_SDK_as_an_Addon | ''Add-on SDK as an Addon.'']] We currently ship the Add-on SDK as a zip file or source code through github. This may not be the best way for us to distribute the SDK. First, we have a built-in automated update mechanism with AMO which also provides support for stable and beta distribution channels. Second, if we can get the SDK to package itself we have a chance for SDK developers to "eat their own dogfood" - testing the packaging and perfomance everyday. Finally, possibly building upon the original prototype as well as Alexandre Poirot's work of porting the SDK to an add-on we can start to offload some of the Builder's time-consuming functions to the client while also avoiding difficult dependencies for Add-on SDK users.
    <th style="text-align: right;">Distribution</th>
    <td style="background-color: #9f9f9f;">individual JS files</td>
    <td style="background-color: #cfcfcf;">XPIs w/embedded Jetpack runtime</td>
    <td></td>
    <td>Jetpack-native packages (JPIs?)</td>
  </tr>


  <tr style="vertical-align: baseline;">
5) [[Features/Jetpack/Add-on_SDK_Debugging | ''Add-on SDK Debugging.'']] Debugging has come a long way since the old style of dumping errors to printf. However, Add-on SDK users might notice...  we dump to printf! There are many debugging additions we can make to the SDK, especially if we take a cue from our awesome web dev tools team. Some of these items could include:
    <th style="text-align: right;">Documentation</th>
* including introspection
    <td style="background-color: #9f9f9f;"></td>
* profiling
    <td style="background-color: #cfcfcf;">bundled w/SDK</td>
* setting breakpoints
    <td>MDC</td>
* stepping through code
    <td></td>
  </tr>


</table>
6) [[Features/Jetpack/Make_Add-on_SDK_Hug_the_Web_Harder | ''Make Add-on SDK Hug the Web Harder.'']] Jetpack has done a great job in embracing open web technologies to create a robust development toolset. However, there are some areas of web development that we don't currently support like XMLHttpRequest and the emerging standard for modules in JavaScript. We need to make sure we are supporting the most common and useful elements of web development to ensure the platform is as inclusive as it can be.


== Milestone One ==
= Non-Goals =


The first milestone was a Mozilla Labs experiment that prototyped Jetpack's vision with a Firefox extension for installing, using, and managing Jetpack-based extensions; a set of high-level APIs for common extension use cases; a simple Bespin-based development environment for coding and testing extensions without having to restart Firefox; and easy distribution of Jetpack-based extensions via a basic software distribution website (the Jetpack Gallery) and developers' own websites.
Three tasks to which we will not set ourselves in 2011:


The milestone was aligned with Firefox 3.5 and achieved in 2009 Q4 with the seventh release of the Firefox extension.
1. Deep extensibility.
The traditional add-on platform, with features like XUL overlays and XPCOM components, was designed for deep extensibility. Indeed, you can do almost anything to Firefox with the traditional platform. But the vast majority of existing and potential add-ons don't need this capability; the remainder can still be implemented using the traditional add-on platform; and projects like Mozilla Labs' Chromeless Browser experiment are better positioned to explore a potential future replacement. The Jetpack project will leave deep
extensibility to the traditional add-on platform and Mozilla Labs experiments.


== Milestone Two ==
2. Apps.
Mozilla, other browser vendors, and other industry participants are hard at work defining standards, UX affordances, and distribution channels for the next generation of web apps. But apps differ from add-ons, even if they sometimes bundle themselves as such for lack of better distribution channels.  The Mozilla Open Web Apps team is kicking ass here and is much better positioned to identify and address the exposure and distribution needs of apps, while Mozilla's developer tools team headed by Kevin Dangoor is the right locus for activity around tools for web developers. The Jetpack project will not build tools for app development and distribution.


The second milestone begins the incubation of the Jetpack for eventual integration into Firefox as a production-quality feature of the browser.
3. Firefox-SDK integration.
The SDK and Builder bundle API implementations with each individual add-on. This strategy, akin to static linking for compiled code, has its downsides, but it allows the products and add-on platform to evolve independently of the Firefox release cycle, avoids dependency hell, and makes it easier to architect and nurture a rich ecosystem of third-party APIs. The Jetpack project will not land its API implementations in the Firefox tree and ship them with Firefox.  Note that the absence of a goal from the priorities list, or its presence
on the anti-list, does not mean we won't accept code that achieves it. To the contrary, provided such contributions don't work at cross-purposes to the core goals of the project, we couldn't be more thrilled to see our technologies get used by the Mozilla and broader open source communities.


It is building a Jetpack SDK with a robust architecture designed to achieve Jetpack's quality, security, and user/developer experience goals; a command-line-based development environment for power developers on which a web-based IDE for casual developers can be built; and distribution of extensions to Firefox users via traditional extension packages (XPIs) and AMO.
So if you're a Thunderbird developer, a web dev tools hacker, a XULRunner appmeister, or anyone else who wants to see Add-on SDK and Builder (or their component parts) better support your own particular use cases (or get re-purposed into your own new products), know that we want to see that too! So please don't hesitate to dream about how the project can help you, talk about your ideas with us, and make them happen.


This milestone is aligned with Firefox 3.6, will be achieved with the initial release of the SDK (0.1), and is scheduled for 2010 Q1.
= Development Plan =
 
The Jetpack team decided during the 1.0 release that we would move our development to a train cycle that closely follows the Firefox development cycle. This was done mostly for maintenance reasons, which allow us to keep up with the new versions of Firefox. This will ensure that developers can have their add-ons rebuilt automatically on the Add-on Builder or AMO to work with the new versions of the browser. In addition, we will be working on our top three priorities with an outlook of 3 to 6 months for each item. Our version numbers will only increase by dots until we land major changes or breaking changes. This will be done to make sure that people recognize that there is something important to recognize with the release. More information about our development plan can be found here: [https://wiki.mozilla.org/Jetpack/Development_Process Jetpack Development Process]
== Milestone Three ==
 
The third milestone continues Jetpack's incubation with a version of the Jetpack SDK that incorporates a reduced-privilege security model to limit the potential surface area of attacks; an l20n-based localization infrastructure that makes it easy to localize extensions and doesn't require developer effort to package/distribute them; a robust library of APIs for common extension use cases; a simple web-based IDE (FlightDeck) for extension development; and support for installing/uninstalling Jetpack-based extensions without restarting Firefox.
 
This milestone is aligned with a future Firefox release (3.6.x? 3.7?), will be achieved with releases of the SDK (1.0?), the IDE, and Firefox, and is scheduled for 2010 Q3/4.
 
== Milestone Four ==
 
The fourth milestone is the culmination of the project's incubation, resulting in a production-quality, stable and robust Jetpack API library that gets integrated into Firefox; a Jetpack-native packaging format supported by both Firefox and AMO; and ECMAScript 5-based API security hardening to further protect against potential extension-based attacks.
 
This milestone is aligned with a future Firefox release (4.0?), will be achieved with that Firefox release, and is scheduled for 2011 Q1/2.
 
= <b>SDK Release Roadmap</b> =
 
== SDK Release 0.1 - March 1, 2010 ==
This release will introduce the new Jetpack platform, specifically its architecture, to extension developers. It will contain a core set of low-level methods that enable developers to produce extensions using the Jetpack platform as a base.
 
== SDK Release 0.2 - March 29, 2010 ==
 
<b>Starter Pack</b>
 
* [https://wiki.mozilla.org/Labs/Jetpack/Reboot/JEP/101 No-Restarts for Install/Update/Uninstall]
* [https://wiki.mozilla.org/Labs/Jetpack/Reboot/JEP/102 Single UI Mechanism (TBD, will work with FF UI on this)]
* [https://wiki.mozilla.org/Labs/Jetpack/Reboot/JEP/103 Panel]
* [https://wiki.mozilla.org/Labs/Jetpack/Reboot/JEP/104 Simple Storage]
* [https://wiki.mozilla.org/Labs/Jetpack/Reboot/JEP/105 Life-cycle (includes first-run)]
* [https://wiki.mozilla.org/Labs/Jetpack/Reboot/JEP/106 Registered Jetpack URLs]
 
 
<b>Web Pack 1</b>
 
* [https://wiki.mozilla.org/Labs/Jetpack/Reboot/JEP/107 Page Mods]
* [https://wiki.mozilla.org/Labs/Jetpack/Reboot/JEP/108 Background Pages]
* [https://wiki.mozilla.org/Labs/Jetpack/Reboot/JEP/109 XHR]
* [https://wiki.mozilla.org/Labs/Jetpack/Reboot/JEP/110 Tab interactions]
* [https://wiki.mozilla.org/Labs/Jetpack/Reboot/JEP/111 Selection]
* [https://wiki.mozilla.org/Labs/Jetpack/Reboot/JEP/112 Context Menu]
 
== SDK Release 0.3 - April 26, 2010 ==
 
<b>Data Pack 1</b>
 
* Settings
* File
* Clipboard
* Passwords
* Places
 
== SDK Release 0.4 - May 31, 2010 ==
 
<b>UI Pack 1</b>
 
* Toolbar
* Drawers
* Awesome Bar
* Pull-down Menus
* Element Styles
 
 
== Future SDK Releases - By the close of 2010? ==
 
<b>UI Pack 2</b>
 
* Gadget (Prism++ via Jetpack)
 
= <b><span style="color: #f00">Legacy</span> Prototype Release Roadmap</b> =
 
The information in this section is from an earlier draft of this roadmap and is pending review/archival.
 
== Jetpack 1.0 Goals ==
 
* '''A seamless install process''': It defeats the purpose of Jetpack to first require users to install Jetpack, then install a particular Jetpack, before using its features. Instead, we need a solution which allows a seamless install process.
* '''Seamless debugging''': No pointless error messages, and all relevant warnings, line numbers, and tracebacks, are displayed.
* '''Enabling API''': An API deep enough to support a large range of add-ons. It is a non-goal in 1.0 to support everything, instead it is to support 80% of the long-tail of add-ons. The exact feature set of the API will be determined by a set of target add-ons (TBD) and feedback from Jetpack authors.
** '''Frozen API''': Although the API may be versioned, we the API will be backwards compatible from 1.0 on.
* '''Beautiful by default''': A set of OS-specific icons, as well as a beautiful look for Jetpacks.
* '''Security-sensitive Import mechanism''': The strength of any API is measured in how easily 3rd parties can extend it. The 1.0 release will have a strong import mechanism, replete with security provisions.
* '''Security''': A functioning security system that mixes code with social protections.
** An AMO-like service with social code-review
* '''Localization story'''
* '''Works on Fennec'''
 
 
== [[Labs/Jetpack/Reboot_Roadmap|Release Roadmap]] ==
<b>Prototype</b>
* 0.1 through 0.4 - 2009-05 to 2009-08
* 0.5 2009-08-19
* 0.6 2009-11-16
* 0.7 2009-12-23
* 0.8 2010-1-30
 
<b>Production</b>
* 0.1 2010-3-1
* 0.2 2010-3-31
 
== Release Details ==
 
=== 0.6 <i>Prototype</i> ===
 
  Target Release
 
* '''Future Graduates'''
** .storage.synced
** .cookies
** .passwords
** .panels
 
* '''Future'''
** .music (w/device integration)
 
=== 0.5 <i>Prototype</i> ===
 
  Target Release: Aug 19
 
* '''Future Graduates'''
** .toolbar
** .panel
** .menu
 
* '''Future'''
** .storage.synced
** .cookies
** .passwords
** .photos (w/device integration)
** +3 3rd party libraries
 
* ''Misc''
** An default icon set
 
=== 0.4 <i>Prototype</i> ===
 
  Target Release: July 16
 
''Features'':
 
* '''Future Graduates'''
** .clipboard
** .contentScript
 
* '''Future'''
** .menu
** .toolbar (both new toolbars, as well as adding to the navigation toolbar)
** .panel (rich overlays)
** .people
** +2 third party "secure" libraries
 
* '''Misc'''
** Bootstrapping
** First run experience
** Settings page per Jetpack
 
* '''Gallery'''
** 0.5 release
 
=== 0.3 <i>Prototype</i> ===
 
  Target Release: 30th June
 
''Features'':
* '''Future'''
** .clipboard (40% used)
** .contentScript
** .selection
 
* '''Future Graduates'''
** Slidebar graduates from the future (JEP, drag'n'drop, etc.)
** Simple Storage (almost every extension needs this)
 
* '''Modules'''
** Fully privileged modules
** First implementation of a "secure" module
 
* '''Misc''':
* Beautiful by default (statusbar stuff CSS problems fixed)
* Simple editorial feature on Jetpack web page
* Documentation solution
* Call for action (small contest?)

Latest revision as of 22:22, 14 December 2011

Jetpackicon.png Jetpack 2011 Roadmap
Owner: David Mason Updated: 2011-12-14
The top three 2011/2012 priorities for Jetpack are: 1) Enable jetpack to always create add-ons that take advantage of the Electrolysis (e10s) to run in a separate process. 2) Create a path for developers using the traditional tools to move to jetpack. 3) Support Firefox Mobile.
Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

Top Priorities

Building upon a very solid 1.0 release in which we met the highest priorities of shipping a great platform with great docs, and outreach, we now need to turn our attention to extending and improving this platform to make it even easier and open it up to even more capabilities and technologies.

To that end, our top priorities for 2011/2012 are:

1) Support Firefox Mobile. As we now all understand, the web experience is moving towards smaller devices, we have to make sure that any developer creating an add-on via Jetpack will find that their add-on just works in mobile. Mozilla cares as much about user choice and personalization on mobile devices as it does on the desktop, Jetpack must reflect that with no work from end-user developers.

2) Enable jetpack to always create add-ons that take advantage of the Electrolysis (e10s) to run in a separate process. Running an add-on in a separate process is important for users and the add-on developer as it makes it much easier to determine if an add-on is affecting the browser's performance. In addition, there may be some security enhancement as its much harder to exploit a vulnerability if its being run in a separate process. For Jetpack, we want to ensure that our users never even have to think about e10s or how to use it for their add-ons to run in a separate process.

3) Add-on Localization API and Service. Its important that Jetpack no longer lingers behind in the the world-wide reach Mozilla has worked hard to obtain. We must have a localization solution that allows our developers to get localized add-ons with minimal effort on their part. Addon localization in the SDK comprises a simple, high-level API for specifying the strings to localize, a localization service to which addons distributed by AMO are automatically submitted for localization, a web application through which localizers can localize addons, and automatic repackaging of AMO-distributed addons with new and updated localizations.

Secondary Priorities

1) Create a path for developers using the traditional tools to move to jetpack. If we are successful in bringing in new developers to creating add-ons for Firefox, we must not forget the developers who have been using the traditional toolset. With the inclusion of features such as e10s and mobile, it becomes imperative that we offer the easiest methods possible to create add-ons that work with these new technologies and platforms. We see Jetpack as being a great path for our current add-on developers to start taking advantage of these new features - as long as we can make the porting equally simple. This work includes creating tools which will automatically help developers port their existing add-ons, as well as a good set of documentation and examples to help them understand the differences in approach.

2) Simplify the Add-on SDK. While Jetpack is a simple development tool to use as compared to the traditional add-ons tools Mozilla has offered, we have to recognize that simplicity opens the door for more participation. With more participation comes a greater democracy of ideas and implementations - all of which can benefit the open web. Simplifying Jetpack even more is a high priority because it is one and the same with Mozilla's mission. The steps we can take to simplify Jetpack are:

  • merge bootstrap.js and components/harness.js, dropping attempts at ff3.6/gecko1 compatibility
  • merge cuddlefish.js and securable-module.js, breaking code that does require("cuddlefish") for other purposes (sub-loaders? control over loading process?)
  • build a XPI for 'cfx run' and 'cfx test' too, reducing the number of supported code paths from two to one
  • enable the main addon code and the addon's own HTML pages to communicate directly with each other (rather than having to communicate though a content script)
  • remove package abstraction for SDK's own APIs, moving their code to top-level lib/, doc/, and test/ directories
  • support putting all addon files into a single top-level directory for simple addons that don't have enough files to justify breaking them up into data/, lib/, and test/ subdirectories
  • resolve relative and root-relative text strings passed to URL parameters relative to the location of the script and top-level addon directory for all URL parameters, respectively, so addons can specify "/data/foo.txt" in place of require("self").data.url("foo.txt")
  • require in content scripts?

3) Add-on SDK: The missing pieces. There are several notable Firefox features we do not yet support. These would be simple APIs to offer support for:

  • Prefs API
  • Sidebar API
  • Add-on Tab API
  • Tab Groups API
  • minimal XPIs
  • packed XPIs
  • addon testing without browser restart

4) Add-on SDK as an Addon. We currently ship the Add-on SDK as a zip file or source code through github. This may not be the best way for us to distribute the SDK. First, we have a built-in automated update mechanism with AMO which also provides support for stable and beta distribution channels. Second, if we can get the SDK to package itself we have a chance for SDK developers to "eat their own dogfood" - testing the packaging and perfomance everyday. Finally, possibly building upon the original prototype as well as Alexandre Poirot's work of porting the SDK to an add-on we can start to offload some of the Builder's time-consuming functions to the client while also avoiding difficult dependencies for Add-on SDK users.

5) Add-on SDK Debugging. Debugging has come a long way since the old style of dumping errors to printf. However, Add-on SDK users might notice... we dump to printf! There are many debugging additions we can make to the SDK, especially if we take a cue from our awesome web dev tools team. Some of these items could include:

  • including introspection
  • profiling
  • setting breakpoints
  • stepping through code

6) Make Add-on SDK Hug the Web Harder. Jetpack has done a great job in embracing open web technologies to create a robust development toolset. However, there are some areas of web development that we don't currently support like XMLHttpRequest and the emerging standard for modules in JavaScript. We need to make sure we are supporting the most common and useful elements of web development to ensure the platform is as inclusive as it can be.

Non-Goals

Three tasks to which we will not set ourselves in 2011:

1. Deep extensibility. The traditional add-on platform, with features like XUL overlays and XPCOM components, was designed for deep extensibility. Indeed, you can do almost anything to Firefox with the traditional platform. But the vast majority of existing and potential add-ons don't need this capability; the remainder can still be implemented using the traditional add-on platform; and projects like Mozilla Labs' Chromeless Browser experiment are better positioned to explore a potential future replacement. The Jetpack project will leave deep extensibility to the traditional add-on platform and Mozilla Labs experiments.

2. Apps. Mozilla, other browser vendors, and other industry participants are hard at work defining standards, UX affordances, and distribution channels for the next generation of web apps. But apps differ from add-ons, even if they sometimes bundle themselves as such for lack of better distribution channels. The Mozilla Open Web Apps team is kicking ass here and is much better positioned to identify and address the exposure and distribution needs of apps, while Mozilla's developer tools team headed by Kevin Dangoor is the right locus for activity around tools for web developers. The Jetpack project will not build tools for app development and distribution.

3. Firefox-SDK integration. The SDK and Builder bundle API implementations with each individual add-on. This strategy, akin to static linking for compiled code, has its downsides, but it allows the products and add-on platform to evolve independently of the Firefox release cycle, avoids dependency hell, and makes it easier to architect and nurture a rich ecosystem of third-party APIs. The Jetpack project will not land its API implementations in the Firefox tree and ship them with Firefox. Note that the absence of a goal from the priorities list, or its presence on the anti-list, does not mean we won't accept code that achieves it. To the contrary, provided such contributions don't work at cross-purposes to the core goals of the project, we couldn't be more thrilled to see our technologies get used by the Mozilla and broader open source communities.

So if you're a Thunderbird developer, a web dev tools hacker, a XULRunner appmeister, or anyone else who wants to see Add-on SDK and Builder (or their component parts) better support your own particular use cases (or get re-purposed into your own new products), know that we want to see that too! So please don't hesitate to dream about how the project can help you, talk about your ideas with us, and make them happen.

Development Plan

The Jetpack team decided during the 1.0 release that we would move our development to a train cycle that closely follows the Firefox development cycle. This was done mostly for maintenance reasons, which allow us to keep up with the new versions of Firefox. This will ensure that developers can have their add-ons rebuilt automatically on the Add-on Builder or AMO to work with the new versions of the browser. In addition, we will be working on our top three priorities with an outlook of 3 to 6 months for each item. Our version numbers will only increase by dots until we land major changes or breaking changes. This will be done to make sure that people recognize that there is something important to recognize with the release. More information about our development plan can be found here: Jetpack Development Process

Retrieved from "https://wiki.mozilla.org/index.php?title=Jetpack/Roadmap-2011&oldid=378970"