We won't drop XPCOM completely; we may even have configurable Mozilla 1 XPCOM compatibility.

We won't bring up Mozilla 2 on mobile devices (but volunteers are welcome to port early and often; Mozilla 2 will fit on such devices much more easily than Mozilla 1 code does).

The goals boil down to competing more effectively with ourselves, with Webkit, Opera's Presto, and even with IE, for all three of the Web, XUL (or equivalent "widget" or "rich client platform" comparable), and C++ embeddable HTML rendering engine platforms. We should aspire to beat the competition on major time, space, and ease-of-use axes, not just show or place.

Ongoing Work

JavaScript:ActionMonkey: Rewriting spidermonkey to use actionmonkey. This is also the man hg branch that Moz2 work is being done in

A Better VCS (Brendan/Preed)

See the great Version Control System shoot-out. We need a better VCS because Mozilla 2 will require more sweeping changes, and more experiments which must be run in parallel, than anything we've done so far. So we need at least

better, cheaper branching

better merge algorithms for updating and landing branches

decentralized operation (no master repository with slave workareas)

good merge-from-CVS capability to track the Mozilla 1.9 trunk where possible

great performance on Windows (this rules out cygwin-ported Linux VCSes)

An important aspect to get straight is the branching topology. We will have many unstable branches running concurrently during Moz2 development. Generally for each task you want sub-task branches (possibly per-author or per-feature) plus a task-integration branch that your group tries to keep building and working most of the time. The ability to chain a new branch to a new buildbot, with a minimum of fuss, is very helpful.

ES4

Ref implementation complete June 07

Merge Tamarin in existing JS APIs

Tamarin Performance Improvements (see above)

JS Trust labels

By combining APIs, code, and ideas from SpiderMonkey and Tamarin, we will build a JS2 virtual machine as part of Mozilla 2. The Tamarin code contribution is a big boost to this effort, and we intend to extend it, not copy code from it. But we need more than today's Tamarin in order to avoid certain pitfalls. We will probably need all of these:

Dynamic optimizations for untyped JS (both Web and XUL JS -- we won't require all XUL JS to be annotated with types).

Profile-directed Ahead Of Time compilation for critical methods (in lieu of XUL FastLoad, to avoid taking a startup performance hit).

We hope to self-host a JS2 compiler on the VM, but if performance can't match or beat the competition (including today's SpiderMonkey), we will have to consider:

Native compiler front end.

While "it would be nice" (sincerely; but also, these are famous last words) to optimize the VM such that the self-hosted compiler beats a C or C++ hand-crafted compiler, we cannot put purity ahead of performance. The trade-off for Tamarin's embedding in the Flash Player is different: offline compilation via the Flex SDK is the rule there, and the self-hosted compiler need only be fast enough for eval requirements (which will be novel to Flash in a future release).

conversion to C++ exceptions, possibly including a new XPCOM C++ binding

identification of C++ ripe for conversion to JS2.

conversion from ad-hoc or Mozilla-private APIs to standard C++ APIs

simple metrics of code complexity, to be regularly compared to other open source projects

Other good ideas for Oink-based tools should be noted on Static Analysis. The "conversion" items above will use the to-be-written (but proven-in-concept) pattern-matching patch-generating tool discussed at another this blog post.