"They're using it at a scale that it wasn't designed for."
The "Harmony" road map starts with an effort to finalise ECMAScript 3.1, essentially a rationalisation of the current version, and produce two interoperable implementations by spring 2009.
"I think you could characterise 3.1 as a maintenance release," says John Neumann, chair of the technical committee. The ECMAScript 3.1 effort will formalise bug fixes but also standardise across all implementations some of the improvements made in the field, Neumann says. That's key, so applications written for one browser will work in another.
After the ECMAScript 3.1 effort, work will then proceed on a more significant ECMAScript successor dubbed Harmony.
The new strategy means that some ideas planned for ECMAScript 4 have been dropped, after being deemed unworkable for the web. Several ECMAScript 4 ideas "have been deemed unsound for the web and are off the table for good: packages, namespaces and early binding," Eich wrote in his blog. But other ECMAScript 4 ideas remain in the mix, though with some changes to make them palatable to the entire technical committee, such as the notion of classes based on ECMAScript 3 concepts combined with proposed ECMAScript 3.1 extensions, he says.
But beyond agreeing that there will be a Harmony effort, the technical committee has yet to figure out what will actually go into the Harmony standard.
Plans for both ECMAScript 3.1 and Harmony call for providing tools to help developers more easily implement security. That plan will require the technical committee to codify security practices; the committee plans to meet this week to discuss security.
"I think a secure ECMAScript will be based on some future revision of ECMAScript," beyond version 3.1, Neumann says.