Features/Jetpack/Simplify the Add-on SDK

Please use "Edit with form" above to edit this page.

Status

Simplify the Add-on SDK
Stage	Development
Status	In progress
Release target	`
Health	OK
Status note	Various work in progress

{{#set:Feature name=Simplify the Add-on SDK

|Feature stage=Development |Feature status=In progress |Feature version=` |Feature health=OK |Feature status note=Various work in progress }}

Team

Product manager	David Mason
Directly Responsible Individual	Irakli Gozalishvili
Lead engineer	`
Security lead	`
Privacy lead	`
Localization lead	`
Accessibility lead	`
QA lead	`
UX lead	`
Product marketing lead	`
Operations lead	`
Additional members	`

{{#set:Feature product manager=David Mason

|Feature feature manager=Irakli Gozalishvili |Feature lead engineer=` |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}

Open issues/risks

`

Stage 1: Definition

1. Feature overview

The Add-on SDK's interfaces (APIs, commands, the required structure for an addon) and implementations are overcomplex in a variety of ways, leading to a higher barrier to entry for new developers, a more difficult developer experience, and a greater risk of bugs than is necessary.

Simplicity is a characteristic of product features, but, like performance and certain other such characteristics, it can also be treated as a feature in and of itself, because the overall simplicity of a software product impacts its usability and quality.

This feature is to simplify the SDK's interfaces and implementations to the degree possible in a variety of ways, including:

• 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?
• Remove some generalization code contained in the python portions of the SDK

2. Users & use cases

The target audience is addon developers. The use case is an add-on developer using the Add-on SDK (either directly or via the Add-on Builder) to build an addon.

3. Dependencies

`

4. Requirements

`

Non-goals

`

Stage 2: Design

5. Functional specification

`

6. User experience design

`

Stage 3: Planning

7. Implementation plan

Many of the items listed in the overview will begin in conjunction with our P1 work so developers do not have to devote 100% of their time to just one feature. Therefore, the status of this full-set feature will be in progress until all items are completed or determined to be part of another feature, or no longer needed or wanted.

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=` |Feature overview=The Add-on SDK's interfaces (APIs, commands, the required structure for an addon) and implementations are overcomplex in a variety of ways, leading to a higher barrier to entry for new developers, a more difficult developer experience, and a greater risk of bugs than is necessary.

Simplicity is a characteristic of product features, but, like performance and certain other such characteristics, it can also be treated as a feature in and of itself, because the overall simplicity of a software product impacts its usability and quality.

This feature is to simplify the SDK's interfaces and implementations to the degree possible in a variety of ways, including:

• 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?
• Remove some generalization code contained in the python portions of the SDK

|Feature users and use cases=The target audience is addon developers. The use case is an add-on developer using the Add-on SDK (either directly or via the Add-on Builder) to build an addon. |Feature dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=` |Feature ux design=` |Feature implementation plan=Many of the items listed in the overview will begin in conjunction with our P1 work so developers do not have to devote 100% of their time to just one feature. Therefore, the status of this full-set feature will be in progress until all items are completed or determined to be part of another feature, or no longer needed or wanted. |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}

Feature details

Priority	P2
Rank	999
Theme / Goal	`
Roadmap	Jetpack
Secondary roadmap	`
Feature list	Jetpack
Project	`
Engineering team	Jetpack

{{#set:Feature priority=P2

|Feature rank=999 |Feature theme=` |Feature roadmap=Jetpack |Feature secondary roadmap=` |Feature list=Jetpack |Feature project=` |Feature engineering team=Jetpack }}

Team status notes

	status	notes
Products	`	`
Engineering	`	`
Security	pass	`
Privacy	`	`
Localization	`	`
Accessibility	`	`
Quality assurance	`	`
User experience	`	`
Product marketing	`	`
Operations	`	`

{{#set:Feature products status=`

|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=pass |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}