development roadmap
Welcome to the Mozilla browser 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:
-
the judgment of the module owners;
-
the fervent wishes of web content authors; and
-
my personal judgment as mozilla.org technical bigshot
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:
-
NGLayout completion. See the
NGLayout Project Page for detailed
to-do lists and schedules.
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.