Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

On Sep 25, 2009, at 9:38 PM, Yehuda Katz wrote:

> Another way to put my earlier concern

Sorry, what earlier concern? You are replying to my reply to Doug  
Schepers on a sub-thread where I didn't see a message from you.


> is: It's impossible to write a
> conforming JS engine that browsers will want to use by only following
> the ES spec - since there's additional, un-speced, behavior that isn't
> in ES that is necessary in order to construct a browser's DOM.

This is a problem to fix. No one is arguing that it's not a problem.  
What's the real topic?


> Consider the following scenario: I write an ECMAScript engine that is
> significantly faster than any existing engine by simply following the
> ECMAScript spec. A browser maker then wishes to use this engine. This
> would be impossible without adding additional (hidden) features to the
> engine to support the DOM. There is nothing in the ECMAScript spec
> that requires the ability (at the very least) to add native extensions
> with arbitrary behavior to the engine.

The ES spec allows extensions, but it cannot require them without the  
extensions being no longer extensions in any sense, rather as  
specified parts of the normative core language. Again I don't know  
what your point here is.


> Is this a requirement ECMA is comfortable with?

What requirement? Your scenario? I have no idea where it came from,  
but it doesn't follow from anything you cited (cited again below).

If you mean we need to specify multiple globals, split windows,  
execution model, etc. -- that's what I've been saying on the main  
thread since the first message, and what Sam's transcription of a  
private message from me tried to say.

Still not sure what your point is,

/be

>
> -- Yehuda
>
> On Thu, Sep 24, 2009 at 3:19 PM, Brendan Eich <brendan@mozilla.com>  
> wrote:
>> On Sep 24, 2009, at 2:43 PM, Doug Schepers wrote:
>>
>> [much appreciated information snipped -- thanks!]
>>
>>> I really don't see how the review process and accountability could  
>>> be much
>>> more open for the development of Web IDL elsewhere, nor is the  
>>> burden on
>>> reviewers that large... it would simply be one more low-traffic  
>>> mailing
>>> list.  Are there other barriers you see?
>>
>> I alluded to employers who are not currently paying W3C members not  
>> wanting
>> their employees participating, even individually. I'll let one  
>> notable
>> example that I know of speak for himself.
>>
>> The "mailing list as firehose" problem can be solved with enough  
>> work, but
>> with two standards groups there is always greater risk of conflict,  
>> and just
>> competition for attention. Two lists is simply one more list than  
>> one list
>> to keep up with.
>>
>> This is a price of collaboration at wider scale, so don't let me  
>> stand in
>> the way, since I've been explicit about being in favor of  
>> collaboration.
>>
>> W3C and Ecma both have transparency issues, but I don't expect  
>> those to be
>> fixed easily. I mentioned them ("People in dark-glass houses ...  
>> [should not
>> throw stones]") in reply to Maciej asserting greater openness on  
>> one side.
>> Again this is not a "barrier" I'm trying to take down right now.
>>
>> /be
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> -- 
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325