Mozilla 2.0 virtual machine goals

  1. Multiple languages supported, including JS, Java, and Python.
  2. Good cross-language integration: inheritance, type matching, etc.
  3. Cross-language debugging, ideally including C++.
  4. One GC to rule them all, preferably one shared GC, not a super-GC ruling a zoo of heterogenous GCs and reference-counting subsystems.
  5. Decent JITed performance, because performance matters when you can least afford to rewrite in C++.
  6. Sandboxed execution security model, type safety, defense in depth.
  7. Part of a larger open source platform . . .
  8. . . . that has momentum and excited developers hacking on it.
  9. A sufficiently open specification process for standardizing and evolving that platform.
  10. New XML language implementations easy to write, plug in, and demand-load (if we had this today, we would use it for non-web standards such as XForms).

The last item means some number of frozen APIs into the content code, e.g. XTF. SVG and existing XUL and HTML widgets may provide a rich enough rendering vocabulary. If we can mix them well using XBL, then we may not need to expose frozen APIs into layout, gfx, etc.

The goal should be minimal, supportable, and composable high-level APIs, where possible. XBL and XTF point the way.

Back to the more programming-language-specific points above: comments welcome on realistic candidates. Obvious and controversial possibilities include Mono, Java (if open source), and Parrot (last I looked, *way* too Perl6-focused, not very mature, not looking likely to mature quickly).

/be

Mozilla 2.0 platform must-haves

  1. libxul.so/libxul.dll, a versioned shared library with minimal, frozen, documented API exports, and fast intra-library calling convention code (so small footprint compared to today’s “GRE” or “XRE”).
  2. xulrunner/xulrunner.exe, so you can write ‘#! /usr/bin/xulrunner’ at the top of a .xul file and get busy.
  3. XUL 2 and XBL 2 — standardized specifications, greater binding language power, more scripting languages, iTunes-like widgets, and working remote XUL/XBL.
  4. SVG support to a useful level, not necessarily the whole 1.1 spec.
  5. Web Forms 2.0.
  6. XForms Basic (or ultra-Basic, details TBD — the heavyweight item is Schema-based validation) support as an optional, downloadable extension.
  7. JavaScript 2.0 support, including ECMAScript for XML support.
  8. Python support, perhaps via Mono (if so, along with other programming languages).

That’s a good start. Comments?

/be

The non-world non-wide non-web

I spent a day at the recent w3c workshop on web apps and compound documents. Due to vacation, that day was the second, so I missed the chance to hear JavaScript praised as the worst invention of all time.

The adolescent sniping and general irrelevance continued on the second day, however. The sad fact is that the w3c is not concerned with the world wide web, AKA the Internet. Rather, the focus for a while now seems to be on vertical tool/plugin and service/cellphone markets, where interoperation is not a requirement, content authors are few and paid by the vertical service provider, and new standards provide livelihoods and junkets for a relative handful of academics, standards body employees, and big company implementers.

Evidence of the vertical nature of the new standards? There are only a few hundred tests for the SVG w3c recommendation. That’s several decimal orders short of what is required just for surface coverage. Often recently, when Hixie hears of a claim about an interesting SVG standard feature, he writes a testcase. Adobe’s plugin too often fails that testcase, although I am sure Adobe SVG tooling produces content that works with the Adobe plugin. Interoperation is a joke.

Real browser vendors, who have to deal with the ugly web as it is, know better. The dream of a new web, based on XHTML + SVG + SMIL + XForms, is just that — a dream. It won’t come true no matter how many toy implementations (including Mozilla implementations — we’ve supported XHTML for years) there are. Long before the w3c gets compound documents working on paper (having missed the chance with SVG 1.0 and 1.1, which ambiguate and conflict with CSS), XAML etc. will leak onto the public web.

What matters to web content authors is user agent market share. The way to crack that nut is not to encourage a few government and big company “easy marks” to go off on a new de-jure standards bender. That will only add to the mix of formats hiding behind firewalls and threatening to leak onto the Internet.

The best way to help the Web is to incrementally improve the existing web standards, with compatibility shims provided for IE, so that web content authors can actually deploy new formats interoperably.

What has this to do with Mozilla’s roadmap? Not much, which is why apart from HTML, CSS, DOM, and SVG, which we support, you probably won’t hear much more about the w3c here. But Mozilla is joining with Opera and others to explore the sort of incremental improvements to HTML proposed by us at the workshop. I expect the resulting specs and implementations to play a significant part in the roadmap.

/be