Features/Jetpack/Module-Sharing

Status

Team

Open issues/risks

`

Stage 1: Definition

1. Feature overview

Since the inception of the Jetpack project, we have always had the goal of being able to easily create, share, and use modules within the Add-ons community. This allows the community to more easily create new functionality as well as keeping the core of the Add-on SDK small and robust. While we do have basic module sharing capability, we want to build a better system that allows a developer to discover new modules, and more easily include them in to her add-on. In addition, we want developers to have a canonical place or method to search for useful modules.

While these goals are basic to understand, the implementation might be tricky as we have to keep in mind the way our current tools work and the fact that we are starting to land the Add-on SDK loader into Firefox itself.

2. Users & use cases

Bob is a developer who likes to create add-ons for Firefox. He uses the SDK and wishes there were an easier way to do authentication with twitter for his new add-on. Bob, while using the SDK, makes a search for already written twitter authentication modules and finds that there are 2 of them. He sees that one module has been used more and reviewed well and decides that he will try it out.

In his add-on code, Bob puts the URL for his chosen twitter auth module into his require statement. When he runs cfx to build his add-on, the module is retrieved from the repository, installed, and used as Bob has included in his code. Bob is happy.

3. Dependencies

`

4. Requirements

`

Non-goals

`

Stage 2: Design

5. Functional specification

There are three types of module sharing to prepare for: Local - a developer loads his own module into his code (we support this now) External - as described above, a url is put in the require statement and the module is loaded and used System- these are modules that already live in Firefox and are loaded at the time of the add-on running.

6. User experience design

`

Stage 3: Planning

7. Implementation plan

The implementation for this system will be done in Three stages:

Phase One: Create the foundations for sharing to happen the way we envision it. This will include having a place for dependencies to live and making sure that the loader will know how to pull in those dependencies.

Phase Two: In this phase, we will work on making sure the tools know how to discover and use external & system modules.

Phase Three: In this phase we will tackle the area of how and where developers find modules. We hope that once we have the first two phases working, we will have a better sense from the community on how they see this system working and will help us better define what this looks like.

More details on descriptions and implementation can be found in this proposal

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

Team status notes