Posted on by Brendan Eich

New roadmap coming

This roadmap update has been much-delayed, as we have juggled priorities and sweated security releases on the AVIARY_1_0_1 branch. Sorry for the delay; I will keep the roadmap up to date much more frequently from now on.

The new roadmap restarts the document with as little repeating boilerplate as possible. Highlights:

  • The main point is to focus near-term work on the Mozilla 1.8 milestone, which is the basis for the rv:1.8 Gecko codebase in Firefox 1.1 and XULRunner.
  • We would like to branch 1.8 by the end of June, in order to open the trunk up for general Mozilla 1.9 alpha 1 milestone development. Sooner would be better, and later is hard to justify.
  • A high priority for Firefox 1.1 at this point is to finish the end-to-end support for the incremental app/extension update work being done based on bsdiff, which has been spearheaded by Darin Fisher.
  • We have also made several major architecture changes (e.g., XPCNativeWrapper automation) for improved chrome scripting security, with one more to land, so security is another high priority that may justify late-breaking changes.
  • Apart from update and security, we won’t take any big changes on the 1.8 branch, instead focusing on quality and polish. So now is the time to cut low-priority or “nice to have, but …” items from your 1.8 buglists.
  • Pending testing results from Deer Park Alpha 1, which just released, we will have a better idea of the order of work remaining.
  • There will be a second Deer Park Alpha, to line up with the 1.8b3 trunk milestone. Here’s the usual diagram, free of hard dates:

branching-2005-05-04

We will construct a detailed schedule for the rest of the release. Until we have a more “real” schedule, the roadmap will be fuzzy about dates. Apart from the absolute priority that Firefox 1.1 be able to update itself in small background-downloaded increments, and that its security and quality be at least as high as Firefox 1.0.x, we have already enabled new platform features such as SVG and <canvas>. These new richer-graphics-for-the-web features are in usable shape, and they deserve testing and experimental usage in XUL and even HTML. We want developer feedback, which we will incorporate into future releases.

In order to help both our XUL platform and (more important) the open-standards-based web to compete with next-generation OSes and their proprietary frameworks, we are rearchitecting Gecko’s graphics subsystem. Here is a picture of Gecko emphasizing its graphics infrastructure as of the 1.8 milestone and Firefox 1.1:

fftracinsm1

Here is where we are headed in 1.9:

gfx-arch-19

We are joining forces with the Cairo Graphics project (this will be no surprise to anyone following the project, in particular roc‘s blog). Together, we can move faster and on more platforms, toward a hardware-accelerated 2D future, and beyond.

As with any large rearchitecture, there will be bumps along the way. But we are not going to rewrite the world at once (never again!). We aim to make changes in smaller increments, that can be done during the 1.9 alpha cycles. So the 1.9 schedule, which I won’t even bother to depict yet, will have a good number of alphas.

Anyway, this is a blog item’s worth of roadmap content, which will show up in a more polished form in the main roadmap soon. Your comments are welcome.

/be

12 Replies to “New roadmap coming”

  1. Could you explain a bit better the two graphs, gfx-arch-1.8.png and gfx-arch-1.9.png.
    Specifically, what is the white wavy line in -1.8.?
    Thanks
    -Jed

  2. Jed: that’s an attempt to indicate that in 1.8, SVG on Windows does not use Cairo, rather it sits on top of native GDI+ pretty directly (a dynamically linked shim avoids hard crash-on-startup dependency on GDI+, which is not on all Windows users’ systems).
    For 1.9, SVG on all platforms including Windows will be layered cleanly on Cairo.
    /be

  6. You never make an iota of sense to the common man. Please consider a brain transplant. [imaginary dashed line connecting iota and brain]

  7. Good stuff as a blog entry now (or 10 days even), but it seems like a lot of it’s about the branch that’s coming up shortly, and all that stuff will be out of date within a couple of months. Unless you’re really really sure you’re going to keep up with updates, why not focus on the 1.9 stuff for this update, even if it’s vague.

  8. Thanks v much – the upcoming roadmap is now much clearer. (and try and disregard all the “knockers” comments above – it’s still v good work you guys are doing and is to be applauded 😉 )

  9. michaell: this is not the roadmap, just a blog sneak preview — there’s a lot to get down, and there is a pressing need for short-term information (we certainly feel it, since we don’t have all the desired dates and plans in order ourselves — but we are getting there).
    Much 1.9 work will be about optimizing Cairo and our graphics code layered on it to render everything, both old and new code paths, as efficiently as needed. The old paths must not degrade from the pre-Cairo Gfx code. That will occupy many people this summer and fall on the trunk.
    Other 1.9 work items were suggested in earlier blog entries here, and in past Mozilla Developer Day presentations I’ve done. For example, we will turn on XUL Python scripting in the 1.9 milestone and derived products. Another example: I am planning to lead a “JS2” (details TBD, in concert with ECMA TG1, but not waiting for a final ECMAScript Edition 4 spec) implementation. Other initiatives are already under way, although a few new projects may be launched.
    Since not all of this will be grand-planned far in advance, I will update the roadmap often enough to guide and track what’s going on. Trying to direct effort six months out is generally a mistake, however. We know what lies before us, and we know that it will take many months of hard work for, e.g., the new graphics architecture to be optimized and fully integrated.
    End-user features for particular apps such as Firefox are one area I’ve never focused on, and I do not expect that to change, although there may be a few global-architecture issues that affect user interface and interaction design. Again, stay tuned.
    /be

  10. Possibly a dumb question but are you planning on releasing 1.8 betas of the combined Mozilla suite? from this. From the picture it looks like Deer Park should have coincided with a rel of 1.8b2 but maybe that is just the releases of the underlying engine not the suite itself?

Comments are closed.