Jetpack/Design Guidelines

From MozillaWiki
< Jetpack
Revision as of 16:24, 3 February 2010 by ChrisHofmann (talk | contribs) (Created page with ' 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 …')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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.
  • Security - Current Addons can "do anything" once installed. Jetpack will be designed to restrict and sandbox the set of capabilities to improve security for users and make the capabilities used by Jetpacks more visiable 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 = options, arg, callbacks?)
    • Minimal API set (make sure we have use case). reduce 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.
    • hiding/encapsulation. say something here about how we will try to enforce and not allow access to or leak jetpack internals.
    • error handling.
    • testing -- APIs will be created in testdriven development process. write the tezt 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.