canmove, Confirmed users, Bureaucrats and Sysops emeriti
2,776
edits
Features/Jetpack/Traditional Addon Conversion to SDK Platform: Difference between revisions
Features/Jetpack/Traditional Addon Conversion to SDK Platform (view source)
Revision as of 16:03, 26 April 2012
, 26 April 2012no edit summary
(Created page with "{{FeatureStatus |Feature name=Traditional Addon Conversion to SDK Platform |Feature stage=Draft |Feature version=TBD |Feature health=OK |Feature status note=Investigating as part...") |
No edit summary |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 2: | Line 2: | ||
|Feature name=Traditional Addon Conversion to SDK Platform | |Feature name=Traditional Addon Conversion to SDK Platform | ||
|Feature stage=Draft | |Feature stage=Draft | ||
|Feature health=OK | |Feature health=OK | ||
|Feature status note=Investigating as part of post-1.0 planning | |Feature status note=Investigating as part of post-1.0 planning | ||
| Line 11: | Line 10: | ||
}} | }} | ||
{{FeaturePageBody | {{FeaturePageBody | ||
|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. | |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. | ||
|Feature users and use cases=The target audience is addon developers who have built one or more addons using the traditional platform. | |Feature users and 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. | ||
|Feature requirements=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. | |Feature requirements=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 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. | 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. | ||
|Feature non-goals=The feature should not attempt to support addons that ship binary components. It should not attempt to provide tools and APIs for traditional addon development. | |Feature non-goals=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. | ||
|Feature functional spec='''Phase One''' | |Feature functional spec='''Phase One''' | ||
| Line 28: | Line 27: | ||
'''Phase Two''' | '''Phase Two''' | ||
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. | 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. | ||
|Feature 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. | |||
}} | }} | ||
{{FeatureInfo | {{FeatureInfo | ||
|Feature priority= | |Feature priority=P2 | ||
|Feature roadmap=Jetpack | |Feature roadmap=Jetpack | ||
|Feature list=Jetpack | |Feature list=Jetpack | ||
|Feature engineering team=Jetpack | |Feature engineering team=Jetpack | ||
}} | }} | ||
{{FeatureTeamStatus | {{FeatureTeamStatus}} | ||
}} | |||