Labs/Jetpack/Reboot/Architecture Overview: Difference between revisions

From MozillaWiki
< Labs‎ | Jetpack‎ | Reboot
Jump to navigation Jump to search
(That other page is not an architectural overview nor canonical. It's to describe current Jetpack status to Firefox team.)
({{Jetpack/Moved to SDK}})
 
Line 1: Line 1:
The Jetpack architecture is designed to provide a variety of
{{Jetpack/Moved to SDK}}
advantages over traditional extension development, while building on
the existing extension architecture in a way that allows both Mozilla
newcomers and veterans alike to easily create powerful, secure
extensions.
 
The key design principles for this new architecture are:
 
* '''Modular functionality'''. Providing a simple, standards-compliant way to create and share modules and packages of code that can exist side-by-side different versions of one another will help encourage code reuse&mdash;not only among Jetpack developers, but among the JavaScript community as a whole.
 
* '''Developer ergonomics'''. It must be as easy as possible for developers to figure out why their code is behaving the way it is. This means a quick edit-compile-test loop, full stack tracebacks when something goes wrong, built-in logging, debugging functionality, and other features present in many modern development environments.
 
* '''High quality'''. Tools and associated best practices should exist to make it as easy and straightforward as possible to create code that is robust and fault-tolerant. This means, for instance, that writing test suites for one's code should be as easy as possible, and ensuring one's code has no memory leaks should be straightforward too.
 
* '''Zero restarts'''. It must be possible for Jetpacks to be installed, uninstalled, and upgraded without requiring the end-user to restart their browser.
 
* '''Security'''. Within the constraints of pragmatism, Jetpacks should obey the Principle of Least Authority, i.e. be given access only to what they need to accomplish their task. This ensures that if the Jetpack is somehow compromised, the user's system is placed at as little risk as possible.
 
= Modular Functionality =
 
The Jetpack architecture uses the CommonJS Standard when
possible. This standard helps ensure that code can be reused across
multiple JS frameworks, such as on a Web page, in a Jetpack, or on a
server. It also serves as a sort of [http://en.wikipedia.org/wiki/Dynamic_linker dynamic linker] that can connect the client of an interface with an actual implementation&mdash;something typically done on the Mozilla platform by XPCOM.
 
The foundation of this standard, the CommonJS module specification, is
quite simple. Here's an example module, contained in a file called
<tt>sue.js</tt>:
 
<pre>exports.add = function add(a, b) {
  return a + b;
}</pre>
 
The <tt>exports</tt> global above starts out as an "empty" object. To
export data, functions, or objects for use by other code, a module
simply "attaches" things to <tt>exports</tt>.  Everything else is part
of the module's private global scope, ensuring that namespace
conflicts don't occur.
 
Using this module from another file is easy:
 
<pre>var sue = require("sue");
sue.add(1, 2);</pre>
 
The <tt>require</tt> global function is used to import our
<tt>sue</tt> module, and it essentially returns the <tt>exports</tt>
object from <tt>sue</tt>.
 
In addition to CommonJS modules, the Jetpack architecture provides a
way to group several modules, their testing suites, documentation,
data files, and other resources into packages.

Latest revision as of 23:56, 4 March 2010

HEY
This page has been superseded by documentation contained in the Jetpack SDK.


Retrieved from "https://wiki.allizom.org/index.php?title=Labs/Jetpack/Reboot/Architecture_Overview&oldid=206179"