Jetpack/Design Guidelines

Jetpack is 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 provide a base set of functionality needed to extend the browser and create a stable set of interfaces around those features to eliminate these incompatibility problems. In a nutshell, Keep Addons Working Across Major Releases! for the benefit of end-users who like using addons and developers who don't want to chase more frequent Firefox and other product release trains.

• Security. Currently, addons can "do anything" once installed. Jetpack is being designed to restrict, isolate, and sandbox the set of capabilities it provides to improve security for users, by extending to addons only the capabilities they need, restrict access to internal implementation details of those capabilities, and make their use of those capabilities more visible to code reviewers and users.

• Usability. Historically, Firefox API design has been limited by the requirements of XPCOM/XPIDL and has not taken advantage of improvements in the expressiveness of the JavaScript language and achievements in API ergonomics by JavaScript libraries. Jetpack will provide a JS-only API with a strong focus on simplicity, productivity, and flexibility.

• Generative
• The goals of Jetpack APIs and development system for extending the browser are
  • Easy to learn
  • Easy to use, even without documentation
  • Hard to misuse
  • Easy to read and maintain code that uses it
  • Sufficiently powerful to satisfy requirements
  • Clear and consistent APIs -- guidelines will outline naming conventions (CamelCase naming, etc..?), 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.
  • Consistent Error Handling to Enable Debugging.
  • Testing -- APIs will be implemented 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 and solid as possible, and then allow extensibility for creating additional experimental features.

These goals inspired by lessons learned in jquery and FUEL library development and present in a talk by jresig (http://video.google.com/videoplay?docid=-474821803269194441# ) and papers on API Design including http://queue.acm.org/detail.cfm?id=1255422 http://lcsd05.cs.tamu.edu/slides/keynote.pdf http://neuroning.com/2006/11/19/on-api-design-guidelines