FUEL/Ideas

Purpose

The purpose of the extensibility framework is to make it easier for extension developers to hook into toolkit and application level systems. The framework will also provide utilities that make accessing toolkit services and application data easier. By providing a known, documented, stable framework for extension developers, extensions can rely less on using internal, undocumented application code and hacks. The result will be more stable extensions, and therefore, a more stable application. Changes in application code should have less of an affect on extensions compatibility.

In addition to making it easier to work with toolkit and application system, the framework will provide general purpose simplification utilities. There are many JavaScript utility frameworks for DHTML, but these usually do not work in Mozilla chrome with XUL and XPCOM. Therefore, the framework will include utilities to make it easier to work with XUL DOM and events inside chrome.

Overview

The extensibility framework is a set of abstractions for toolkit and application level systems. Toolkit systems are usually frozen and documented, but can be hard to use or understand. The framework will provide utilities to make it easy to use toolkit services and components. On the other hand, application systems are not well documented and could change from release to release. The frame work will provide utilities to access application level data and hook into application level events and notifications.

Toolkit objectives:

1. Make it easier to access interfaces, components and services.
2. Provide convenience wrappers for enum / launching windows
3. Provide a threaded wrapper for nsIProcess
4. Provide convenience wrapper for file, text or stream upload via XHR (multipart POSTing)

Application objectives:

1. Make it easier to access data and meta data
   1. Bookmarks
   2. Microsummaries
   3. Search Providers
2. Provide convenient way to monitor application events/notifications
   1. Startup sequence [toolkit -> application ->application windows]
   2. Extension sequence [download -> install/fail -> updates -> uninstall]
   3. Downloads [start -> progress -> finish]
3. Provide convenient ways to interact with application UI
   1. Adding toolbar buttons
   2. Chrome to Content communication

Simplification objectives:

1. Provide jQuery / Prototype convenience tools for working inside chrome
   1. Easy XUL DOM builder
   2. Hookup events to elements in JS (not XUL) and promote using best practices (commands, keys, and controllers)
   3. Localization utilities for accessing string bundles
2. Clipboard management
   1. Application.clipboard: clipboard could have "text" property for easy get/set of plain and unicode text

Random Thoughts

We should put as much code as possible in some form of namespace. Possible names? "MOZILLA"

Accessing services/interfaces/components should be easier. We could allow shorthand access like this:

var prefService = Components.classes["@mozilla.org/preferences-service;1"]
                            .getService(Components.interfaces.nsIPrefBranch2);

// or

var os = Components.classes["@mozilla.org/observer-service;1"]
                   .getService(Components.interfaces.nsIObserverService);

// or

var cs = Components.classes['@mozilla.org/consoleservice;1']
                   .getService(Components.interfaces.nsIConsoleService);

These could become:

var ps = MOZILLA.getService("@mozilla.org/preferences-service;1", "nsIPrefBranch2");

// or

var os = MOZILLA.getService("@mozilla.org/observer-service;1", 
"nsIObserverService");

// or

var cs = MOZILLA.getService("@mozilla.org/consoleservice;1", "nsIConsoleService");

Of course, for flexibility, we should allow quick access to classes as well:

var prefs = MOZILLA.getClass("@mozilla.org/preferences-service;1");

// Now you can call getService to whatever you need

For commonly used services, we could even have named "getters" like this:

var prefBranch = MOZILLA.PrefBranch();

var os = MOZILLA.ObserverService();

var cs = MOZILLA.ConsoleService();

Developers seem to have problems with observer notifications. When they are fired, or what significance of the notification. There are also problems with determining what is an event (addEventListener) and what is a notification (addObserver). Basically, developers want to know when a resource is available (UI element or service) and what event or notification they need to use to figure that out.

What if we provided a means to hook developer code to an event/notification without needing to know the details of the element or notification name. Something like:

MOZILLA.DelayedExecute("xpcom-services-started", doMyStartup);

MOZILLA.DelayedExecute("browser-services-started", doMyRefresh);

MOZILLA.DelayedExecute("browser-ui-loaded", doMyToolbarSetup);

MOZILLA.DelayedExecute("quit-application-granted", doMyShutdown);

We would create a maintained list of "events" that would be mapped to events/notifications in the toolkit and browser.

See also other notes in the Talk:Mozilla_Extensibility_Library page.