Labs/Jetpack/JEP/13

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

JEP 13 - Enabling Experimental Jetpack Features

• Champion: Aza Raskin <aza at mozilla dot com>
• Editors: Atul Varma <atul at mozilla dot com>
• Status: Implementing
• Type: API Track
• Created: 5 June 2009
• Reference Implementation: None
• JEP Index

Introduction and Rationale

This JEP describes a method for enabling experimentation with experimental Jetpack features, or features that aren't stable/frozen.

There is a tension in Jetpack development between (a) moving quickly and being agile, and (b) creating solid APIs that are future proof. We need to have and be both. As a way to compromise, this JEP proposes adding an import mechanism that allows access to not-quite-yet-ready Jetpack features.

One of the requirements for this import mechanism is that as few code changes are required for any particular Jetpack as a feature is moved from experimental to permanently in the core.

Proposal

We need to have some functionality for easily accessing experimental functionality that may be added in the future, but whose APIs are likely to change.

Inspiration for this comes from Python's __future__ module. Essentially, in Python you can call

from __future__ import foo

which adds whatever functionality that foo yields to the Python script you are writing. In Jetpack, we do not have the same syntax as Python, so instead we propose adding a new function to the base namespace of Jetpack called importFromFuture.

Importing the Future

The general syntax for importing from the future is as follows:

jetpack.future.import( stringMountPath )

Where stringMountPath is a string that enumerates where, starting from the jetpack base, the feature will be mounted. To get a list of what mount paths are available, see the "Reading the Future" section below. Some examples of using future.import are as folows:

// jetpack.storage.sqlite is currently undefined.
jetpack.future.import("storage.sqlite");
var mydb = jetpack.storage.sqlite.create("blah");

// jetpack.T1000 is currently undefined
jetpack.future.import("T1000");
jetpack.T1000();

The nice thing about such syntax is that once storage.sqlite is formally accepted into the core, the author can just remove the jetpack.future.import() call and their code will "just work" (barring any other changes that were made when the functionality was integrated into the core, of course).

Reading the Future

To determine what features are importable from the future, use:

var list = jetpack.future.list()

It returns an array containing the set of potential stringMountPath as used in jetpack.future.import().