Features/Jetpack/CFX in JS
Status
| CFX in JS | |
| Stage | Planning |
| Status | In progress |
| Release target | ` |
| Health | OK |
| Status note | Trying to split the train in multiple wagons. Between planning and starting development. |
Team
| Product manager | Dave Mason |
| Directly Responsible Individual | Alex Poirot |
| Lead engineer | Alex Poirot |
| 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
CFX is currently pure python code. We want to slowly migrate this to JavaScript based code, possibly leaving a small python shim to handle command line support.
2. Users & use cases
During first development phase, the very first audience will be the Jetpack team. It allows us to dogfood the SDK itself while building such complex application. And as most of the team is Javascript oriented, it will be easier to modify and review code of cfx in future.
On last iterations, addon developers will be able to build addons without any other dependency other than: Firefox and one addon, "cfx in JS". Currently, on the first hand, developers have to install python in order to build addons. This is particulary hard for people on Windows, where command line application using Python isn't that easy to install and use. On the other hand, they may use Addon-builder, whose only requirement is Firefox. But Addon-Builder is more limited than cfx (localization and preferences support is still to be done), and isn't always usable on slow/bad internet connections.
On the half way of this project, CFX in JS will allow Addon-Builder to build addons on client side instead of server side. That's a key feature in order to allow Addon-Builder team to start working on an offline-capable version of this service.
3. Dependencies
`
4. Requirements
`
Non-goals
Execute "Add-on SDK as an Addon" or "Ship SDK via AMO" features. CFX in JS shouldn't aim to ship the SDK in a XPI in order to host it on AMO, even if it will most likely help these two goals. It may just end up being a requirement for them.
Stage 2: Design
5. Functional specification
`
6. User experience design
`
Stage 3: Planning
7. Implementation plan
This work can easily be splitted in multiple, eventually parallel steps:
- Be able to execute Javascript code hosted in an addon from cfx in python
Then we would be able do implement following CFX workflow steps in JS:
- Install and execute an Addon - Generate the XPI out of the manifest - Compute the manifest out of packages/modules - Read/seek for packages/modules on filesystem - Interpret command line options - Build a command line application with mozilla-platform/Firefox - Write shell/bash scripts in order to setup cfx environnement (equivalent of source bin/activate)
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
Main tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=746124
Stage 5: Release
10. Landing criteria
`
Feature details
| Priority | P1 |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | Jetpack |
| Secondary roadmap | ` |
| Feature list | Jetpack |
| Project | ` |
| Engineering team | Jetpack |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
Usefull links:
https://jetpack.etherpad.mozilla.org/cfx-js
https://etherpad.mozilla.org/cfx-js-2013
https://github.com/mozilla/addon-sdk/wiki/CFX-py
