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

On Sep 24, 2009, at 11:25 AM, Brendan Eich wrote:

> 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).

Any TC39 members whose employers can't join could perhaps become  
Invited Experts to the W3C Web Applications Working Group, if that  
facilitates review.

> 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.

We already have a spec in progress and it already has a home, so  
starting the conversation with a suggestion to move the work elsewhere  
struck me as odd and potentially disruptive.


>> 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.

That would probably best be done via a recommendation not to use  
catchalls  in new APIs (in the Web IDL spec perhaps).

>
>
>>> 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.

Indeed, because the variance in what's out there makes life more  
difficult for authors. I expect it's not possible to get rid of  
prototypes from ECMAScript DOM bindings given the constraints of Web  
compatibility.

>
> 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).

I think we are in agreement that collaboration would enable a better  
outcome here. All I meant to do is to point out the proper W3C Working  
Group for coordination.

>
>>> 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).

Workers are technically a Web Apps WG spec and not part of HTML5  
proper any more. They provide an asynchronous messaging shared-nothing  
model, while preventing access to most browser-specific APIs in  
anything but the main thread. It would be nice to study whether in- 
language concurrency features could work together with the Workers  
model rather than being completely separate.

>
>
>> 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.

Well, it seems bad to me for the spec to state a requirement that  
won't be followed.

> 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.

Specifying more about multiple global objects would be good, but I  
think it's not a case where current browser behavior violates the  
ECMAScript spec, so it's not really the same issue.

>
> 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.

ECMAScript could just allow host embeddings to make the outermost  
scope chain entry be something other than the global object. The main  
downside is that this is more loose than is needed and could  
technically allow crazy unreasonable things. But it may not be  
possible to fully specify the behavior at the ECMAScript level, since  
it depends on the notion of navigation. There may be a way to provide  
a more narrowly tailored hook.

Regards,
Maciej

Received on Thursday, 24 September 2009 18:54:12 UTC