Labs/Extensions2

Extensions 2.0: Ent

State of the Art

Add-Ons are the lifeblood of Firefox -- enabling anyone to make the browser theirs.

We have thousands of add-ons, and add-on creators. It's a leading community and ecosystem of innovation, with over 1 billion downloads. Part of it's success has been the ease with which anyone can add to the browser -- enabling everyone else to customize their Firefox to their passions. But it still requires learning XUL, and RDF, and packaging. It's not particularly open to casual, hobbiest programmers.

Manifesto*

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 a working add-on for each of the major add-on types should take less than 5 minutes from start to running in the browser.

(1) Use Web Technology: HTML, Javascript, and CSS should be the only tools required to create an add-on. No XUL or XBL required. If you are already a web developer, you know all you need to write an add-n.

(2) 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.
 

(3) 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.
 - 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.
 

(4) 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.
 

(5) 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.

• It may seem odd that this is referred to as a manifesto, as it is not hundreds of pages long and has not been written by someone with an unkempt beard and filthy military surplus clothing. We believe in simplicity in all its forms. That is why we are inclined toward brevity. And why we shower.

Milestone 1

A working prototype done as a Feed Manager for Ubiquity.