canmove, Confirmed users
548
edits
Jetpack/Roadmap-2011: Difference between revisions
no edit summary
m (moved Labs/Jetpack/Roadmap to Jetpack/Roadmap) |
No edit summary |
||
| Line 6: | Line 6: | ||
|updated=Feb 2011 | |updated=Feb 2011 | ||
|status=Draft | |status=Draft | ||
|description=The top three 2011 priorities for Jetpack are: 1) | |description=The top three 2011 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 /> | ||
}}<section end=summary /> | |||
{{draft|}} | {{draft|}} | ||
= Priorities = | = 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 are: | |||
1) ''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. | |||
2) ''Create a path for developers using the traditional tools to move to jetpack.'' If we are successful in bringing in new developers creating new add-ons we must not forget the developers who have been using the traditional toolset. With the inclusion of 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 these 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. | |||
3) ''Support Firefox Mobile.'' As we now all understand that 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. | |||
= Secondary Priorities = | |||
1) ''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. | |||
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: [[https://wiki.mozilla.org/Jetpack/Development\_Process | Jetpack Development Process]] | |||