Labs/Jetpack
< Labs
|
THIS PAGE IS A WORKING DRAFT | 
|
| The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page. |
Overview
Jetpack is a project to explore new & innovative approaches to extensibility of the browser.
Background
TBD
Guiding Principles
Enhancing the browser should be as easy as it is to write a web page. The time between having an idea, and an implementation should be as short as possible: Programming the "hello world" add-on for each of the major add-on types should take less than 5 minutes from start to running in the browser.
- Use Web Technology
- HTML, Javascript, and CSS should be the only tools required to create an add-on. If you are already a web developer, you know all you need to be comfortable writing an add-on.
- Develop Once, Run Anywhere, Any Version.
- Writing an add-on for Firefox should run in Firefox Mobile, Thunderbird, and anywhere else that's apropos. Programming should be by intent: You should be able to say, "My add-on should expose UI in a toolbar-like thing", and it will. Whatever a toolbar-like thing happens to be on Fennec, Firefox, etc.
- As a developer, you shouldn't have to worry about some detail-of-Firefox internals changing breaking your extension. Add-ons will work through a version'ed facade-pattern so that you won't be in a constant struggle to keep your extension working with the latest FF edition.
- Secure
- Add-ons should have access to only the privileges they need. They should be as safe and secure as Firefox proper.
- Add-ons should be easy to code review -- making security problems much more shallow.
- Add-ons should not interfere with each other.
- Security models should be easy to innovate. Security is ripe for improvement, and we should be enabling easy experimentation and deployment, letting security researchers mix social trust models, object component models, and as-of-yet unthought-of models.
- Security should always be presented in human-terms, not technical-terms.
- More secure add-ons should enjoy a more streamlined user experience for installation.
- Easy to code
- The API should be small, short, concise.
- Great design patterns should be easy to follow with good supporting APIs
- Should allow open innovation in APIs via easy inclusion of 3rd party libraries.
- Changes made during development should be reflected in real-time in the browser
- Great documentation. Tutorials, snippets, examples.
- Easy to install, easy to use, easy to keep up-to-dates
- Add-ons should feel light-weight: they should be installable without restart and in two clicks or less
- Add-ons should automatically up-date securely. This process should be easy for users and developers alike.
Design Constraints
[...]
Proposed Roadmap
Milestone 1
Functional prototype API that follows the Guiding Principles and provides enough capability to implement these target add-ons:
Milestone 2
Get to a point where we can start implementing something like social bookmarking (e.g. Delicious Bookmarks) via the API:
- Access to prefs
- Access to cookie jar or alternatively the ability to have its own sandboxed cookie jar
- Web service calls via Firefox network prefs (i.e. proxy settings)
- mozStorage
- Ability to modify menus/keyboard shortcuts
- New Sidebar, new toolbar, and adding/removing buttons from Fx toolbar
- Ability to add search plugins (but not remove unrelated plugins)
Resources
- Initial investigation into the capabilities used by top add-ons today, and in particular, which de facto API calls they rely upon.
- Rough notes on potential API structure