Jetpack/Design Guidelines: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 20: Line 20:




These goals inspired by lessons learned in jquery and FUEL library development and present in a talk by jresig.
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://video.google.com/videoplay?docid=-474821803269194441#
 
also
http://queue.acm.org/detail.cfm?id=1255422
http://queue.acm.org/detail.cfm?id=1255422
http://lcsd05.cs.tamu.edu/slides/keynote.pdf
http://lcsd05.cs.tamu.edu/slides/keynote.pdf
and others papers mentioned at
http://neuroning.com/2006/11/19/on-api-design-guidelines
http://neuroning.com/2006/11/19/on-api-design-guidelines

Revision as of 20:42, 3 February 2010

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 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