Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

On Sep 24, 2009, at 10:48 AM, Maciej Stachowiak wrote:

> On Sep 24, 2009, at 9:47 AM, Brendan Eich wrote:
>
>>> Probably the best thing to do is to provide detailed technical  
>>> review of Web IDL via the W3C process.
>>
>> Expertise on both sides of the artificial standards body divide may  
>> very well be needed. The rest of this message convinces me it is  
>> needed.
>>
>> One problem with inviting review via the W3C process is getting  
>> attention and following too many firehose-like mailing lists. es-discuss@mozilla.org 
>>  is at most a garden hose, which is an advantage.
>>
>> Another problem is that not all Ecma TC39 members are W3C members  
>> (their employers are not members, that is).
>
> The converse of all these problems would arise if the spec became an  
> ECMA spec.

I'm not advocating that, personally -- I'm explicitly encouraging some  
kind of collaboration across an artificial divide.

This may be difficult for many reasons, but where the spec ends up is  
less important to me (and if you make me choose either-or, I prefer  
w3's RF to Ecma's RAND on first principles) than that we have good  
collaboration without requiring every TC39 member to join w3c (if  
possible).

Do we have to agree on where the spec ends up before collaborating? I  
hope not, especially since it seems likely both ES specs and W3C ones  
may need to contain sub-specs that hook together, possibly involving  
common pieces duplicated among the specs.


> Indeed, possibly worse, because ECMA has no formally defined process  
> for external review of a specification (though ECMA subgroups could  
> define their own process presumably).

We've had external review of ES5 drafts, and ES4 and ES3.1 materials  
before them, for years. This list hears all about the many updates to http://wiki.ecmascript.org/ 
.. We also publish meeting notes freely (we used to publish the formal  
minutes but doing so, IIRC, did run afoul of Ecma's rules -- but the  
notes are much more complete and useful IMO).


> We could recommend avoiding catch-alls as a best practice. However,  
> many legacy DOM interfaces require catch-all behavior, so it can't  
> be completely eliminated. If we want to restrict host objects to  
> what WebIDL allows, but not break the Web, then catch-all getters  
> and putters have to be among the things it allows.

The problem is containing the old patterns, heading off the temptation  
to use them in new APIs.


>> Beyond this tarpit, we're interested in the best way to linearize  
>> multiply-inherited WebIDL interfaces onto prototype chains, or  
>> whether to use prototype chains at all -- or in the seemingly  
>> unlikely event ES grows first-class method-suite mixins, binding  
>> WebIDL inheritance to those. We would welcome use-cases and  
>> collobaration, at least I would. Who knows what better system might  
>> result?
>
> Yes, linearization of multiply-inherited interfaces (and multiple  
> interfaces that are present but not inherited) is something that  
> could use careful review and a better design. When I said "these are  
> largely Web IDL issues" I mean "not directly issues for the HTML  
> Working Group". I did not mean to imply that TC 39 shouldn't have  
> input - it should.

There's probably a better future beyond prototype chains, and I think  
the odds of finding that world and colonizing it are greater if we  
collaborate somehow. The current situation is making the best of de- 
facto standards, rationalizing what's out there.

Possibly TC39 members need to do the main work on mixins, and then  
propose something coherent for WebIDL to bind to. But I know of folks  
not active in TC39 or not even Ecma mebmers, who are able to  
participate in the public HTML5 lists (and of course in whatwg.org),  
who do want mixins a la Ruby modules in JS, and their input would help  
us make some kind of progress.

But this separation of "producers" and "consumers" is artificial, and  
it may miss critical information not expressed in mythical waterfall  
requirements docs one might imagine the parties exchange. Systems R&D  
benefits from mixing up the experts and opening the silos to cross  
disciplines, interest areas, programming audiences, and less  
defensible boundaries to-do with standards body politics.

The current division of labor between "core language" (Ecma) and DOM/ 
WebAPI/WebIDL (W3C) has its advantages, don't get me wrong. But  
obviously some things have fallen through the cracks (multiple  
globals, split windows, execution rules).


>> The term I used was "execution model". "scope" is a mis- 
>> transcription.
>
> Are there specific issues other than the concurrency model for  
> storage APIs?

There are AFAIK interop issues to-do with modal dialogs and events in  
major browsers, but I haven't retested lately. Possibly HTML5 has this  
all nailed down and browser bug fixes are all that's left to do.

Beyond this, concurrency via workers is great for certain use-cases  
but not enough for others.

In TC39 we are talking about formalizing the run-to-completion  
execution model of JS, along with asynchronous message passing  
concurrency. In particular, we're looking at Promises (precedent from  
E) and Futures (differently, in MultiLisp and Alice-ML). At least one  
contributor on es-discuss has advocated lower-level components such as  
dataflow variables.

It's too early to predict what we'll do but I hear strong consensus in  
favor of asynchronous messaging and shared-nothing, with higher-level  
abstractions such as Promises favored over lower-level concurrent  
programming features such as dataflow variables.

This is for the same reasons given on es-discuss over the last three  
years against adding sharp low-level tools such as call/cc, instead  
supporting higher-level (very) delimited continuations (Pythonic  
generators as in JS1.7).


> If ES5 has requirements on this that match ES3, then it has a  
> requirement that Firefox, Safari and Chrome (and I think Opera?) are  
> all violating, and likely will continue to violate for the  
> foreseeable future. That seems like a problem. (Unless we convince  
> ourselves that the split global object pattern somehow doesn't  
> actually violate the ECMAScript spec.)

It's a violation, for sure, but no one will be struck down by  
lightning. We can live with it a bit longer.

Much of the hoped-for multiple global objects spec that is notoriously  
missing from ES1-5 did not appear as an informative document (an Ecma  
TR), but it still needs to be done, and it looks like Hixie et al.  
have done some of it. A future ES spec would need to say more to work  
with the HTML5 spec, and we might want the core language to say a lot  
more, not just the minimum necessary to interoperate with the other  
spec.

WindowProxy and Window go a step beyond multiple globals, of course,  
splitting each global in two (or one proxy and one or more globals  
under navigation with cached history).

Do we need a WindowProxy in the core language? I'm not sure, but if  
not then there has to be some other way of specifying how |this| in  
global code binds to the outer window rather than the inner (Ecma  
global). We didn't try to make something up here for ES5.

/be

Received on Thursday, 24 September 2009 22:18:16 UTC