These arguments against the proposal are not persuasive. I remain of the opinion that the GlobalScript proposal has merit.<div><br></div><div><br><div class="gmail_quote">On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson <span dir="ltr">&lt;<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Mon, 17 Aug 2009, Dmitry Titov wrote:<br>
&gt;<br>
&gt; Currently there is no mechanism to directly share DOM, code and data on<br>
&gt; the same ui thread across several pages of the web application.<br>
&gt; Multi-page applications and the sites that navigate from page to page<br>
&gt; would benefit from having access to a shared &quot;global script context&quot;<br>
&gt; (naming?) with direct synchronous script access and ability to<br>
&gt; manipulate DOM.<br>
<br>
</div>This feature is of minimal use if there are multiple global objects per<br>
application. For instance, if each instance of GMail results in a separate<br>
global object, we really haven&#39;t solved the problem this is setting out to<br>
solve. We can already get a hold of the Window objects of subwindows (e.g.<br>
for popping out a chat window), which effectively provides a global<br>
object for those cases, so it&#39;s only an interesting proposal if we can<br>
guarantee global objects to more than just those.</blockquote><div><br></div><div>&gt; we really haven&#39;t solved the problem this is setting out to solve</div><div><br></div><div>What problem do you think this is trying to solve? I think you&#39;re misunderstanding the motivation. The motivation is frame/page navigation performance once an app is up and running.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
However, we can&#39;t. Given that all frames in a browsing context have to be<br>
on the same thread, regardless of domain, then unless we put all the<br>
browsing contexts on the same thread, we can&#39;t guarantee that all frames<br>
from the same domain across all browsing contexts will be on the same<br>
thread.<br></blockquote><div><br></div><div>As proposed, there is nothing that forces things into a single thread. Those contexts that happen to be on the same thread can benefit from the feature.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
But further, we actually wouldn&#39;t want to anyway. One of the goals of<br>
having multiple processes is that if one tab crashes, the others don&#39;t. We<br>
wouldn&#39;t want one GMail crash to take down all GMail, Google Calendar,<br>
Google Chat, Google Reader, Google Search, and Google Voice tabs at once,<br>
not to mention all the blogs that happened to use Google AdSense.<br>
<br>
Furthermore, consider performance going forward. CPUs have pretty much<br>
gotten as fast as they&#39;re getting -- all further progress is going to be<br>
in making multithreaded applications that use as many CPUs as possible. We<br>
should actively moving away from single-threaded designs towards<br>
multithreaded designs. A shared global script is firmly in the old way of<br>
doing things, and won&#39;t scale going forward.<br>
<div class="im"><br></div></blockquote><div><br></div><div>&gt; moving away from single-threaded designs</div><div><br></div><div>I don&#39;t think there is any move away for the concept of a &#39;related set of browsing context&#39; that are required to behave in a single threaded fashion?  There is a place for that, it is a greatly simplifying model that nobody wants to see removed.</div>
<div><br></div><div>The proposal is to add GlobalScripts to that set of browsing contexts, and where convenient , for the UA to have two different related sets share the same GlobalScript... &quot;where convenient&quot; is key.</div>
<div><br></div><div>&gt; old way</div><div><br></div><div>Ironic... the global script is a decidedly application centric proposal. Whereas the vast majority of HTML is decidedly page centric. So disagree that this is &quot;firmly&quot; rooted in the old way of doing things.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<br>
&gt; Chat application opens separate window for each conversation. Any opened<br>
&gt; window may be closed and user expectation is that remaining windows<br>
&gt; continue to work fine. Loading essentially whole chat application and<br>
&gt; maintaining data structures (roster) in each window takes a lot of<br>
&gt; resources and cpu.<br>
<br>
</div>Use a shared worker.<br>
<br>
I know that some consider the asynchronous interaction with workers to be<br>
a blocker problem, but I don&#39;t really understand why. We already have to<br>
have asynchronous communication with the server, which holds the roster<br>
data structure, and so on. What difference does it make if instead of<br>
talking to the server, you talk to a worker?<br></blockquote><div><br></div><div>Provided you can talk to the &#39;shared worker&#39; in the same fashion you can talk to the server (XHR)... you have a point here when it comes to keeping application &#39;state&#39; in memory and quickly retrieving it from any page in the application. But, using a worker  does nothing to keep application &#39;code&#39; required to run in pages &#39;hot&#39;... code that does HTML DOM manipulation for example can&#39;t run in the worker.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<br>
&gt; Finance site could open multiple windows to show information about<br>
&gt; particular stocks. At the same time, each page often includes data-bound<br>
&gt; UI components reflecting real-time market data, breaking news etc. It is<br>
&gt; very natural to have a shared context which can be directly accessed by<br>
&gt; UI on those pages, so only one set of info is maintained.<br>
<br>
</div>Again, use a shared worker. The UI side of things can be quite dumb, with<br>
data pushed to it from a shared worker.<br></blockquote><div><br></div><div>The key phrase was &quot;directly accessed by the UI&quot;... not possible with a shared worker.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
<br>
&gt; A game may open multiple windows sharing the same model to provide<br>
&gt; different views at the game objects (as in flight simulator).<br>
<br>
</div>You wouldn&#39;t even want the logic (simulator) in this case to be on the<br>
same thread as the renderers. In fact ideally you&#39;d want everything on a<br>
different thread so that you got the best performance out of the system<br>
-- each renderer, each simulator, etc.<br>
<div class="im"><br></div></blockquote><div> </div><div>Kind of an academic discussion but... you may want a representation of the model to be shared by all of its views (that happend to be on the same UI thread). Perhaps the &#39;simiulator&#39; would be running on a background thread and sending async commands to mutate the model (as seen by views) as the simulation runs.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<br>
&gt; In an email application, a user may want to open a separate &quot;compose&quot;<br>
&gt; window for a new email, often after she started to &quot;answer in place&quot; but<br>
&gt; realized she&#39;d like to look up something else in the mailbox for the<br>
&gt; answer. This could be an instantaneous operation if the whole html tree<br>
&gt; and the compose editor script were shared.<br>
<br>
</div>This is possible without a shared global script -- it&#39;s possible now, in<br>
fact. Just open a window, and graft the DOM tree from the original window<br>
into the new window.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<br>
&gt; Such multiple-window use cases could be simpler and use much less<br>
&gt; resources if they had access to a shared Global Script Context so there<br>
&gt; is no need to re-initialize and maintain the same state in all the<br>
&gt; pages. Having direct, same-thread DOM/JS access to this context makes it<br>
&gt; possible to avoid loading and initialization of repetitive code and<br>
&gt; data, makes separate &#39;UI windows&#39; simpler and independent.<br>
<br>
</div>There&#39;s no need for this case to use shared _global_ script; a shared<br>
script just between the original window and the popped-out window is<br>
sufficient (and already supported).<br>
<div class="im"></div></blockquote><div><br></div><div> </div><div>You can&#39;t rely on opener since it can be closed at any time... including prior to the openee being loaded.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
&gt; Another case is an application that uses navigation from page to page using<br>
&gt; menu or some site navigation mechanism. Global Script Context could keep the<br>
&gt; application state so it doesn&#39;t have to be round-tripped via server in a<br>
&gt; cookie or URL.<br>
<br>
</div>You can keep the state using sessionStorage or localStorage, or you can<br>
use pushState() instead of actual navigation.<br></blockquote><div><br></div><div>* GlobalScript is a friendlier, easier, more accessible means of accompishing things </div><div><br></div><div>* LocalStorage is acutally persistent which is not want is wanted. Would need to recognize and ignore stale data.</div>
<div><br></div><div>* PushState is an odd artifact of page-centricity. Its there (partly at least) to help avoid having to perform frame navigations at all. </div><div><br></div><div>Maybe a better approach would be to make frame navigations not so costly.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I haven&#39;t added the Global Script Object proposal to HTML5. Even if we<br>
were to add it to the platform, it would probably belong in its own<br>
specification rather than in the HTML spec. We would also probably need<br>
implementation experience before specifying it. But I really don&#39;t think<br>
it is the direction we should be taking the platform in. Granted,<br>
programmers today don&#39;t want to use threads -- but, well, tough. All<br>
indications are that that&#39;s what the programming model of the next few<br>
decades is going to be; now is the time to move that way. We shouldn&#39;t be<br>
adding features that actually move us back to the single-threaded world.<br>
<font color="#888888"><br></font></blockquote><div><br></div><div>&gt; it would probably belong in its own spec</div><div>Maybe this would fit better under the banner of w3c wep apps?</div><div><br></div><div>&gt;  We would also probably need implementation experience before specifying it</div>
<div>Does that mean you won&#39;t help produce a draft spec of this for us to work with?</div><div><br></div><div>&gt; programmers today don&#39;t want to use threads -- but, well, tough</div><div>A resounding conclusion of our experience with Gears was the using workers/threads is hard. There is a place for them, but they&#39;re not such a good fit in other places.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">
--<br>
Ian Hickson               U+1047E                )\._.,--....,&#39;``.    fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a>       U+263A                /,   _.. \   _\  ;`._ ,.<br>
Things that are impossible just take longer.   `._.-(,_..&#39;--(,_..&#39;`-.;.&#39;<br>
</font></blockquote></div><br></div>