Features/Jetpack/Simplify the Add-on SDK
Status
| Simplify the Add-on SDK | |
| Stage | Development |
| Status | In progress |
| Release target | ` |
| Health | OK |
| 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 | ` |
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
`
Feature details
| Priority | P2 |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | Jetpack |
| Secondary roadmap | ` |
| Feature list | Jetpack |
| Project | ` |
| Engineering team | Jetpack |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | pass | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
