Ian Hickson (2014-06-10T21:08:57.000Z)
On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
> > 
> > Is my understanding correct that the HTML spec should invoke this 
> > algorithm when the HTML spec creates the Window object?:
> > 
> >   
> > http://people.mozilla.org/~jorendorff/es6-draft.html#sec-initialization
> 
> Not exactly, although if you had said "first" Window object then maybe 
> you statement would be correct.
> 
> As you know, an ECMAScript environment may have multiple co-existent 
> "global objects".  The ES spec. abstracts the concepts associated with 
> each global object as a "Realm". All ECMAScript code execution must take 
> place in the context of a Realm so an initial Realm must be established 
> before any ES code executes.

What is an "ECMAScript environment" in this context? Is it the scripting 
engine behind a unit of related similar-origin browsing contexts? Or is it 
the scripting engine associated with a particular event loop?

   http://www.whatwg.org/html#unit-of-related-similar-origin-browsing-contexts
   http://www.whatwg.org/html#event-loop

In the case of two pages that are running in different origins, each with 
their own Window object, does the ES spec attempt to answer the question 
of how those two scripts should interact if they access each others' 
Window objects? Or is that something for the HTML spec?


> Section 8.5 defines the initialization process that occurs for an ES 
> engine before any ES code executes.  It includes establishing the first 
> Realm.  Whether or not that initial Realm actually corresponds to the 
> first "Window" is something you need to decide. For example, I can 
> imagine that for some hosts the first Realm might actually some sort of 
> utility Realm that is used for loading code and "forking" user Realms.

Such a "utility Realm" sounds like an implementation detail that wouldn't 
appear in a spec, though, no? Would it be exposed or detectable in any way 
from aithor script?

There's not really a "first" Window from the point of view of the HTML 
spec. I'm not sure how an initial Realm would really map to a browser.


> 8.5 can't be performed for each Window object that shares a common ES 
> engine because it essentially restarts the entire ES engine.  Instead, I 
> would expect that the steps of InitializeFirstRealm (8.5.1) to be 
> approximately what should be called for each Window object.

Ok. I think part of my confusion comes from step 7, then, which says "one 
or more" scripts. I think if that was changed to "zero or more", I could 
say in the HTML spec that the Initialization steps run as required by the 
ES spec, and that in HTML implementations, step 7 must obtain no scripts. 
Then, separate from this, I would call CreateRealm() to get a realm and 
then call InitializeFirstRealm(realm) with that realm? Is that right?



> This suggests that InitializeFirstRealm is poorly named.  Perhaps it 
> should be renamed InitializeHostRealm. There may be additional 
> refactoring that is needed between 8.5 and 8.5.1.

I'm happy to use whatever terms you think are best.


> > If so, what should the browser do in step 7? I don't fully understand 
> > how this is supposed to work. Suppose a page is just:
> > 
> >   <body>
> >   <script> alert(document.body.innerHTML); </script>
> >   <script> alert(document.body.innerHTML); </script>
> > 
> > If I read the #sec-initialization algorithm correctly, the scripts 
> > will execute back-to-back with no change in the DOM, so they'll output 
> > the same text. But the Web requires that these output different text, 
> > since the second <script> element won't be in the DOM when the first 
> > executes:
> 
> ES doesn't know anything about the DOM, external script dependencies, 
> etc. The ES model is that it has a simple queue (populated by the host) 
> of script execution tasks and that the execution of the scripts in the 
> queue take place in order.
>
> A simple command-line ES host probably would, as part of step 7, add a 
> ScriptEvaluationTask to the queue for each script file listed on the 
> command-line.  They would then be evaluated in sequence.
> 
> However, you don't have to do that and step 7 isn't the only place you 
> can add new ScriptEvaluationTasks.

If step 7's "one or more" is what is intended (as opposed to the "zero or 
more", see above), what is the script that a browser obtains in step 7?


> I would imagine you would maintain your own queues and dependency 
> algorithms that track order and DOM update dependencies such as between 
> the two script tags in your example. You would then only EnqueueTask a 
> ScriptEvaluationTask when it DOM update dependencies has been satisfied.

Well, we want to make sure that browsers only have one dependency 
algorithm, we wouldn't want to have redundancy there. See the "Integrating 
the Webs' dependency systems" thread from a few weeks back. I'm trying to 
understand how ES6's loading logic works so that I can figure out how to 
integrate or extend it to handle the more elaborate needs of other parts 
of the Web platform, so that we can e.g. have image loading handled by the 
same logic as module loading, since they need to share network resources, 
can have interdependencies, etc.


> Alternatively, you might define a new kind of ES Task, let's call it a 
> SyncDOMTask. Then at step 7 you might EnqueueTask a DOMSyncTask onto the 
> "ScriptTasks" queue between the two ScriptEvaluationTasks.

Are these tasks related in any way to the HTML spec's task queues and 
event loop mechanism? Should we integrate these somehow also?


> I understand that this is all pretty vague and leaves a lot up to you.

That's fine. :-)

I just want to make sure it's all well-defined, I don't mind doing the 
heavy lifting.


> But I need to define ES execution in a host independent manner.  I'm 
> trying to provide the building blocks that you and other hosts need to 
> describe how their complex environment-specific semantics integrate with 
> the baseline ES execution semantics.

Cool.


> > (Also, how could step 6's substeps ever get triggered?)
> 
> Working backwards, step 5 does many things, some of which are specified 
> as having error conditions and exceptions, so I have to take into 
> account what happens if any errors occur. Step 6, just says that if they 
> do then the startup of the ES environment has failed.  If an implementor 
> can prove that they [can't] trigger any of those error conditions then 
> they don't have to worry about it.  But for completeness, I do.

Do you have an example of how any of those steps could fail?

It seems to me that if step 6 triggers, the whole scripting engine has 
failed to start up, which seems like it should be something that is 
non-conforming. :-)


> It's up to you to define what you initially enqueue in step 7.  It could 
> be nothing (step 7 currently says "one or more", it probably should say 
> "zero or more").

Zero or more would, I think, fix my confusion here.


> Step 8 just says to dispatch the next pending ES Task.  You need to do 
> that to actually get things started.

NextTask seems like it is somewhat redundant with the HTML event loop 
mechanism. Ideally I think I'd like to have the hooks set up so that when 
a task completes on the ES side, it just returns to the HTML event loop, 
which then does its stuff, and eventually calls back into the ES spec to 
run the next script.


> It occurs to be that these implementation-specific extension points may 
> be hard to find as they hare buried as steps in several algorithms.  in 
> my next revision I see if I can define an abstraction operation 
> corresponding to each extension points.  They we will have a list of 
> operations that a host must define.

That would certainly help, yes.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
domenic at domenicdenicola.com (2014-06-17T20:38:44.708Z)
On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:

> Not exactly, although if you had said "first" Window object then maybe 
> you statement would be correct.
> 
> As you know, an ECMAScript environment may have multiple co-existent 
> "global objects".  The ES spec. abstracts the concepts associated with 
> each global object as a "Realm". All ECMAScript code execution must take 
> place in the context of a Realm so an initial Realm must be established 
> before any ES code executes.

What is an "ECMAScript environment" in this context? Is it the scripting 
engine behind a unit of related similar-origin browsing contexts? Or is it 
the scripting engine associated with a particular event loop?

- http://www.whatwg.org/html#unit-of-related-similar-origin-browsing-contexts
- http://www.whatwg.org/html#event-loop

In the case of two pages that are running in different origins, each with 
their own Window object, does the ES spec attempt to answer the question 
of how those two scripts should interact if they access each others' 
Window objects? Or is that something for the HTML spec?


> Section 8.5 defines the initialization process that occurs for an ES 
> engine before any ES code executes.  It includes establishing the first 
> Realm.  Whether or not that initial Realm actually corresponds to the 
> first "Window" is something you need to decide. For example, I can 
> imagine that for some hosts the first Realm might actually some sort of 
> utility Realm that is used for loading code and "forking" user Realms.

Such a "utility Realm" sounds like an implementation detail that wouldn't 
appear in a spec, though, no? Would it be exposed or detectable in any way 
from aithor script?

There's not really a "first" Window from the point of view of the HTML 
spec. I'm not sure how an initial Realm would really map to a browser.

> 8.5 can't be performed for each Window object that shares a common ES 
> engine because it essentially restarts the entire ES engine.  Instead, I 
> would expect that the steps of InitializeFirstRealm (8.5.1) to be 
> approximately what should be called for each Window object.

Ok. I think part of my confusion comes from step 7, then, which says "one 
or more" scripts. I think if that was changed to "zero or more", I could 
say in the HTML spec that the Initialization steps run as required by the 
ES spec, and that in HTML implementations, step 7 must obtain no scripts. 
Then, separate from this, I would call CreateRealm() to get a realm and 
then call InitializeFirstRealm(realm) with that realm? Is that right?

> This suggests that InitializeFirstRealm is poorly named.  Perhaps it 
> should be renamed InitializeHostRealm. There may be additional 
> refactoring that is needed between 8.5 and 8.5.1.

I'm happy to use whatever terms you think are best.

> ES doesn't know anything about the DOM, external script dependencies, 
> etc. The ES model is that it has a simple queue (populated by the host) 
> of script execution tasks and that the execution of the scripts in the 
> queue take place in order.
>
> A simple command-line ES host probably would, as part of step 7, add a 
> ScriptEvaluationTask to the queue for each script file listed on the 
> command-line.  They would then be evaluated in sequence.
> 
> However, you don't have to do that and step 7 isn't the only place you 
> can add new ScriptEvaluationTasks.

If step 7's "one or more" is what is intended (as opposed to the "zero or 
more", see above), what is the script that a browser obtains in step 7?

> I would imagine you would maintain your own queues and dependency 
> algorithms that track order and DOM update dependencies such as between 
> the two script tags in your example. You would then only EnqueueTask a 
> ScriptEvaluationTask when it DOM update dependencies has been satisfied.

Well, we want to make sure that browsers only have one dependency 
algorithm, we wouldn't want to have redundancy there. See the "Integrating 
the Webs' dependency systems" thread from a few weeks back. I'm trying to 
understand how ES6's loading logic works so that I can figure out how to 
integrate or extend it to handle the more elaborate needs of other parts 
of the Web platform, so that we can e.g. have image loading handled by the 
same logic as module loading, since they need to share network resources, 
can have interdependencies, etc.


> Alternatively, you might define a new kind of ES Task, let's call it a 
> SyncDOMTask. Then at step 7 you might EnqueueTask a DOMSyncTask onto the 
> "ScriptTasks" queue between the two ScriptEvaluationTasks.

Are these tasks related in any way to the HTML spec's task queues and 
event loop mechanism? Should we integrate these somehow also?

> I understand that this is all pretty vague and leaves a lot up to you.

That's fine. :-)

I just want to make sure it's all well-defined, I don't mind doing the 
heavy lifting.

> But I need to define ES execution in a host independent manner.  I'm 
> trying to provide the building blocks that you and other hosts need to 
> describe how their complex environment-specific semantics integrate with 
> the baseline ES execution semantics.

Cool.

> Working backwards, step 5 does many things, some of which are specified 
> as having error conditions and exceptions, so I have to take into 
> account what happens if any errors occur. Step 6, just says that if they 
> do then the startup of the ES environment has failed.  If an implementor 
> can prove that they [can't] trigger any of those error conditions then 
> they don't have to worry about it.  But for completeness, I do.

Do you have an example of how any of those steps could fail?

It seems to me that if step 6 triggers, the whole scripting engine has 
failed to start up, which seems like it should be something that is 
non-conforming. :-)

> It's up to you to define what you initially enqueue in step 7.  It could 
> be nothing (step 7 currently says "one or more", it probably should say 
> "zero or more").

Zero or more would, I think, fix my confusion here.

> Step 8 just says to dispatch the next pending ES Task.  You need to do 
> that to actually get things started.

NextTask seems like it is somewhat redundant with the HTML event loop 
mechanism. Ideally I think I'd like to have the hooks set up so that when 
a task completes on the ES side, it just returns to the HTML event loop, 
which then does its stuff, and eventually calls back into the ES spec to 
run the next script.

> It occurs to be that these implementation-specific extension points may 
> be hard to find as they hare buried as steps in several algorithms.  in 
> my next revision I see if I can define an abstraction operation 
> corresponding to each extension points.  They we will have a list of 
> operations that a host must define.

That would certainly help, yes.