Changes

The version numbers, branch names, feature lists, schedules, and indeed basic <i>physics</i> of this roadmap are still very much under discussion. Please do not place large bets or name children around the elements of this roadmap at this time. We have been fortunate to have feedback and input from a number of smart and energetic people, and seek much more such input to help refine this document over the course of the development it describes.

__TOC__

This roadmap describes the planned capabilities of the Mozilla platform, often known as "Gecko", in the 1.9 release. The product delivery vehicle for this platform will be explored, discussed, and refined in another roadmap process, to which this document will soon link.

A rough attempt to categorize these development areas can be found below. Some elements could reasonably be categorized multiply, so tags would be better than categories. Please bear with our taxonomy.

Graphics and layout changes represent some of the most invasive work proposed for the Gecko 1.9 development cycle. They form the core of the architectural shifts in 1.9, and are considered to be the most difficult and riskiest elements.

* "Reflow branch"

The development of the Mozilla suite of applications, from the earliest days of Seamonkey to the current Firefox 1.5 release, has demonstrated the promise of developing significant infrastructure and application logic in JavaScript, rather than the fragile world of Mozilla's portable C++ dialect. Over the course of that development, though, many limitations in the language and our implementation have come to hinder our development efforts, and the JavaScript 2 work in Gecko 1.9 seeks to address many of them.

Apart from all the new language features (for more details, stay tuned to the [http://weblogs.mozillazine.org/roadmap/ roadmap blog]), the JS2 implementation should be significantly faster and easier to debug, both from script and from a graphical debugger such as Venkman. Debugging support in major IDEs is possible (more than possible in one IDE that's already working on it).

Significant potential contributors in both the Python and XUL application development communities have long wanted access to Python's set of libraries and its capabilities as an application development language. So in addition to JavaScript, which is the default web and XUL scripting language, we plan to extend the reach of Gecko and XUL to the Python world.

(N.B.: Mozilla does not intend to distribute the C-Python runtime with its applications or frameworks, so application developers who wish to take advantage of these capabilities will need to provide for this dependency in their installers or packaging. Stub or streaming installer capabilities in the Firefox/XULRunner based on Gecko 1.9 will probably help a great deal to ease the extra download for Python-less users.)

The XUL and XBL languages have served Mozilla development very well, and are often taken as a model for XML-based UI development in other circles. In some cases, however, our implementations or their old specifications are incomplete, inconsistent, insufficiently robust, or not amenable to some important use cases (including remote XUL applications or rich mixing with other content types such as HTML or SVG). We seek to address these limitations, and generally improve the XUL and XBL development experience, with work in Gecko 1.9.

* Template builder

The recent resurgence in Web application development has demonstrated the significant power and capability of Web technologies, as well as some key areas of desirable improvement.

* Client-local storage

For many application developers, putting Mozilla technology inside or underneath their applications has been a bittersweet experience. While they are rightly excited to have the power of the Mozilla platform at their disposal, the state of our embedding interfaces and application-launch facilities have created significant impediments to their productivity, and introduced expensive fragility into their environments. While we wish to see the plight of these developers improve, we do not believe that the "second-class" nature of 3rd party applications can be entirely wiped from our world.

* Embedding APIs, widgets, and frameworks

In addition to the above new and enhanced capabilities, there are several important areas of improvement that resist even the preceding attempt at categorization. They are no less important for that mismatch.