Features/Jetpack/Traditional Addon Conversion to SDK Platform
|Traditional Addon Conversion to SDK Platform|
|Status note||Investigating as part of post-1.0 planning|
|Product manager||David Mason|
|Directly Responsible Individual||David Mason/Myk Melez|
|Product marketing lead||`|
Stage 1: Definition
1. Feature overview
Most existing Firefox addons are built on the traditional addon platform. Their developers would benefit from the improvements in the new addon platform provided by the Add-on SDK, especially as Firefox/Gecko developers make changes to the browser (such as loading content in separate processes) that will break traditional addons.
2. Users & use cases
The target audience is addon developers who have built one or more addons using the traditional platform. For these developers, we will make sure that porting their existing add-ons over is as simple as possible, with tools and documentation to help them along in the process.
The feature should make it possible to run, test, and package a traditional addon using the SDK's functionality. It should automatically convert addon metadata from the traditional format to the new one.
It should provide developers with documentation that explains which SDK features map to which features of the traditional platform and gives tips and tutorials for converting a traditional addon to an SDK-based addon.
It should identify kinds of chrome modification and suggest SDK APIs that developers can use to make similar kinds of modifications. It should identify XPCOM services and automatically convert them to CommonJS modules. It should identify code that runs at startup and automatically convert it to the addon's main code.
The feature should not attempt to support addons that ship binary components and should make that clear in the documentation. It should not attempt to provide tools and APIs for traditional addon development.
Stage 2: Design
5. Functional specification
Make it possible to use the SDK to run and package a traditional addon from a directory containing the traditional addon's code in the filesystem layout associated with a traditional addon XPI. Automatically convert addon metadata from the traditional format to the new one. Make it possible to test the addon using the SDK's unit testing features.
Write documentation that explains which SDK features map to which features of the traditional platform and gives tips and tutorials for converting a traditional addon to an SDK-based addon.
Develop tools that identify kinds of chrome modification and suggest SDK APIs that developers can use to make similar kinds of modifications. Develop tools that identify XPCOM services and automatically convert them to CommonJS modules. Develop tools that identify code that runs at startup and automatically converts it to the addon's main code.
6. User experience design
Stage 3: Planning
7. Implementation plan
Quality Assurance review
Stage 4: Development
Stage 5: Release
10. Landing criteria
We have determined that with the release of our support for e10s, we will have to break our low-level APIs (not the commonly used high-level APIs). Because of this, it is best if we deliver any tools and messaging around this feature until after we have landed this breaking-change feature.
|Theme / Goal||`|
Team status notes