Jetpack/Design Guidelines

From MozillaWiki
< Jetpack
Revision as of 19:58, 3 February 2010 by ChrisHofmann (talk | contribs)
Jump to navigation Jump to search

Jetpack APIs and features provided are intended to improve the following areas of Firefox extensibility

  • Compatibility - Large numbers of current addons require work at each major release to maintain compatibility. A major design goal for Jetpack is to encapsulate a base set of features needed to extend the browser and create a stable set of APIs around those features to eliminate these incompatibility problems. In a nutshell, Keep Addons Working Across Major Releases! for the benefit of end-users that like using addons, and developers who don't want to case more frequent Firefox and other product release trains. [ Maybe say something here about Hiding/Encapsulation how we will try to enforce and not allow access to or leak jetpack internals, or just link to more details on that]
  • Security - Current Addons can "do anything" once installed. Jetpack will be designed to restrict, isolate, and sandbox the set of capabilities to improve security for users, by extending only the capabilities needed by Jetpacks to a jetpack program, and to make the capabilities more visible to code reviewers and users.
  • Generative
  • The Jetpack APIs and development system for extending the browser will be made as simple as possible, as easy to learn, and as easy to maintain as possbile
    • Clear and consistant APIs -- guidelines will outline naming conventions (CamelCase?), placement and position of arguments (jquery like? options, arg, callbacks?)
    • Minimal API Set -- Make sure we have solid use cases for each API and have reduced to common root.
    • Complete, Comprehensive & Orthogonal APIs across the full API set - find all the common attributes/arguments (add, remove, get, set) make a grid and make sure its complete.
    • Consitent Error Handling to Enable Debugging.
    • Testing -- APIs will be implimented in test driven development process. write the test first, then develop support for the api to pass the test.
    • Extensibility. The goals list above all strive to keep the base set of supported APIs as minimal as possible, and then allow extensibility for creating additional experimental features.