You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is
highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If
there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

development roadmap

In my experience, the best maps contain historical notes and sightseeing tips.
A software roadmap in particular must keep integrating the present as it passes
by, or it soon becomes useless. That kind of map records design decisions and
their rationales. More important, such a map reflects unforeseen terrain and
unexpected inventions as they emerge, rather than starting from some
(unrealistic) fixed architecture and proceeding through mundane implementation.

brief history

It has been over five months since I posted to
mozilla.general
my
then-current thoughts on the Mozilla browser development schedule.
That schedule listed only one large feature, mail/news integration, and put off
enumerating the rest until "later, [...] barring a better idea."

Since then, a lot of great work has been done by all mozilla.org developers,
fixing warnings and bugs, porting and cleaning up code, improving performance,
refining downloadable chrome, setting up the autoconf build system, etc.
But the mail/news code from Netscape never arrived.
The features most demanded by content developers (incremental layout
with reflow, correct CSS, a Level-1 DOM) have been hard to implement on the
old codebase. And developers who have wanted to "just add a hook", a la
Emacs and
its extension languages, have found the old layout and FE code less
hospitable than they would like.

Well, now is later, and we do have a better idea or three.

where we're going

It's time to stop banging our heads on the old layout and FE codebase. We've
pulled more useful miles out of those vehicles than anyone rightly expected.
We now have a great
new layout engine that can view hundreds of
top websites.
We have a convincing proof-of-concept for an
XPFE.
Why not use these two new projects in Mozilla, to solve a bunch of longstanding
problems? All of the following combined to say that it is time for the
Mozilla browser project to use XPFE and NGLayout:

Not only will many bugs and lacks be resolved, the road ahead can better
support a full mail client, user-scriptable hooks, and many other clients
and proxy-like modules.

Moving to XPFE and NGLayout means moth-balling all of the old-style FEs, and
of course mozilla/lib/layout and its friends.
Coordinated development will cease right away on the
old layout code, XFE, and all of the
other FEs.

Note however that most back-end modules carry forward with XPFE and NGLayout;
many already work with NGLayout as-is, while some have been #ifdef'ed.
While we won't break old layout and FEs intentionally, evolution of all the
back-end modules common to old and new layout will tend to
rot the old codebase. We've already CVS-tagged the mozilla tree with the
label MozillaSourceClassic_19981026_BASE to facilitate mothballing
and archaeology (there's also a MozillaSourceClassic_19981026_BRANCH
branch tag for retrograde development).

re-introduction

This document will serve as a narrative roadmap for mozilla browser development.
It won't be a schedule, although schedules should be attempted that refer to
the terrain recorded and projected here.
It will state rules of the road, or the design
principles we'd like to employ, to build on the value of XPFE, NGLayout, and
modularity using XPCOM.
It will list major items of work. And I'll update it over time to reflect
reality.

Nothing (apart from accurate history) in this roadmap should be taken as
irrevocable. Although we try to avoid unduly revisiting decisions, we welcome
all developer comments and corrections. Let controversy bloom if it needs to.
Just give us your evidence and reasons, and we at mozilla.org will correct our
course and this map to match the actual terrain.

design principles

Here are the browser road rules.
Some of these points are concrete design decisions more than highfalutin'
principles. But we think they reflect sound ideas (for example, autoconf
captures feature dependencies better than our old Unix build system's platform
macros and consequent #if defined(linux) || ... tests in the code).

External development counts more than convenience or ease-of-habit for
internal-to-Netscape developers. The Netscape X-heads, for example,
have moved all of their mail usage except for I'm-out-sick-today and any
truly-proprietary messages to the
mozilla.unix newsgroup. Likewise with NGLayout hackers and the
mozilla.layout group. So it shall be for all development.

Fresh mail and news clients will be designed and
implemented jointly by Netscape and external developers, using open source
methods, and this time with an open source database
(which I think is likely to be
Berkeley DB).
The new mail/news code will use NGLayout for HTML rendering. It shall
use as much XPFE-like cross-platform widgetry as it can; it shall use
thin-mail techniques akin to
Ender and
Shack.

As much as possible, UI structure should be implemented using HTML or XML
and the NGLayout engine. Style should be expressed using CSS where
doing so makes sense, and doesn't require non-standard extensions to CSS.
Structure that can be queried, modified, and superposed from remote sources
should probably be RDF, expressed in its XML syntax.
Actions should be implemented
(or at least, be implementable) via well-defined events
and their JavaScript handlers

Modules will use
XP-IDL and XPCOM to specify and query
their programmatic interfaces.
That way, all modules are scriptable without requiring all interface
creators to write repetitive-yet-tricky script-engine glue by hand.
Also, parts of the system may be distributed across thread, process, and
machine boundaries using automatically generated stubs. This distribution
potential is a distant second goal, except where single-threaded code
restrictions require us to implement an
apartment
threading model.

Any scripting hooks above and beyond the scriptable-C++ entry points that
we get by using XP-IDL must be designed and specified using IDL extensions.
The crucial principle here is to make all useful parts of the browser
easy to script. What's more, events must be easy to "hook" or handle in a
flexible way, say using JavaScript. More on this point will be written
in the XPCOM-Connect document.

autoconf
will be the one true Unix-hosted build system for the modules you
checkout and build en masse to make a browser that runs on Unix.
Module owners will have to maintain only their module's
Makefile.in and configure.in scripts for Unix,
not both of those and gmake Makefiles.
(This principle does not apply to NSPR, which is a separately-built
prerequisite of the browser; it may be that the Berkeley DB
follows NSPR into separately-built prerequisite status, eventually.)

X-heads
believe the time is right to move from Motif to
GTK+, the leading
fully-open-source X-based UI toolkit.
The general principle here, mentioned above in the
mail/news paragraph in connection with Berkeley DB, and of course behind
autoconf adoption, is that Mozilla must use the best open source solution
to solve a well-understood problem.

major work items

Each of the following tasks constitutes a major milestone.
This list isn't even partially ordered, but it should be, to express
dependencies. It should be topologically sorted and scheduled, too (later).
It shall be refined to include sub-tasks and missing items of work.
For now, it's a roughly-ordered brain dump of what I think we'll all be doing
in the next few months:

In light of the "open source solution" principle, the widget library
used by NGLayout needs to be ported from Motif to GTK+.

The old composer/editor was tightly coupled to old layout. NGLayout
has a rich DOM API that perhaps (with more event work) could form
the basis for the new editor. In any case, Mozilla must have an HTML
composer/editor, and it should be embeddable via an OBJECT or
TEXTAREA TYPE="text/html" tag.

XPFE design and implementation. There is a very preliminary
set of design documents , but they are subject to
change and evolution based on the design principles above, and interested
developers' input.

Back-end modules such as RDF and JavaScript are more-or-less ready to go,
but their interactions, especially their execution model interactions,
need analysis. Also, memory consumption and things like garbage collector
scheduling require a "whole system" analysis.

Mail/news XPFE and modular back-ends need to be designed and implemented,
or in a few cases evolved from existing Mozilla code such as
mozilla/lib/libmime.

The XP-IDL compiler and IDL specs for all interfaces must be written,
tested, and deployed as part of the build system.

The JavaScript XPCOM-Connect runtime, by which JS can call C++ methods
using runtime type information, and convert results to JS types, must be
built. The good news is that some of it will resemble LiveConnect. The
bad (or good, for hackers who enjoy it) news is that we need some assembly
code to implement each platform's Invoke method, where platform
is a pair: (cpu instruction set architecture, compiler-and-cpu-determined
calling conventions).

Conversion of all Unix builds to autoconf. Currently, NGLayout is built
by mozilla/nglayout.mk.
If we follow the existing browser build model, it should be built by the
Makefile generated from mozilla/Makefile.in and
mozilla/configure.in.

For Windows builds, at the least mozilla/nglayout.mak and
mozilla/client.mak need to unify under the latter name. But it
seems possible to use autoconf even on Win32, along with cygwin32 tools.
Perhaps some ATL-like dependency will prevent it, but it should be given
a fair shot.