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"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>></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>
><br>
> Currently there is no mechanism to directly share DOM, code and data on<br>
> the same ui thread across several pages of the web application.<br>
> Multi-page applications and the sites that navigate from page to page<br>
> would benefit from having access to a shared "global script context"<br>
> (naming?) with direct synchronous script access and ability to<br>
> 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'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's only an interesting proposal if we can<br>
guarantee global objects to more than just those.</blockquote><div><br></div><div>> we really haven'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'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'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'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't want to anyway. One of the goals of<br>
having multiple processes is that if one tab crashes, the others don't. We<br>
wouldn'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'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't scale going forward.<br>
<div class="im"><br></div></blockquote><div><br></div><div>> moving away from single-threaded designs</div><div><br></div><div>I don't think there is any move away for the concept of a 'related set of browsing context' 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... "where convenient" is key.</div>
<div><br></div><div>> 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 "firmly" 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>
> Chat application opens separate window for each conversation. Any opened<br>
> window may be closed and user expectation is that remaining windows<br>
> continue to work fine. Loading essentially whole chat application and<br>
> maintaining data structures (roster) in each window takes a lot of<br>
> 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'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 'shared worker' in the same fashion you can talk to the server (XHR)... you have a point here when it comes to keeping application 'state' in memory and quickly retrieving it from any page in the application. But, using a worker does nothing to keep application 'code' required to run in pages 'hot'... code that does HTML DOM manipulation for example can'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>
> Finance site could open multiple windows to show information about<br>
> particular stocks. At the same time, each page often includes data-bound<br>
> UI components reflecting real-time market data, breaking news etc. It is<br>
> very natural to have a shared context which can be directly accessed by<br>
> 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 "directly accessed by the UI"... 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>
> A game may open multiple windows sharing the same model to provide<br>
> different views at the game objects (as in flight simulator).<br>
<br>
</div>You wouldn't even want the logic (simulator) in this case to be on the<br>
same thread as the renderers. In fact ideally you'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 'simiulator' 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>
> In an email application, a user may want to open a separate "compose"<br>
> window for a new email, often after she started to "answer in place" but<br>
> realized she'd like to look up something else in the mailbox for the<br>
> answer. This could be an instantaneous operation if the whole html tree<br>
> and the compose editor script were shared.<br>
<br>
</div>This is possible without a shared global script -- it'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>
> Such multiple-window use cases could be simpler and use much less<br>
> resources if they had access to a shared Global Script Context so there<br>
> is no need to re-initialize and maintain the same state in all the<br>
> pages. Having direct, same-thread DOM/JS access to this context makes it<br>
> possible to avoid loading and initialization of repetitive code and<br>
> data, makes separate 'UI windows' simpler and independent.<br>
<br>
</div>There'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'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">
> Another case is an application that uses navigation from page to page using<br>
> menu or some site navigation mechanism. Global Script Context could keep the<br>
> application state so it doesn't have to be round-tripped via server in a<br>
> 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'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't think<br>
it is the direction we should be taking the platform in. Granted,<br>
programmers today don't want to use threads -- but, well, tough. All<br>
indications are that that'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'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>> 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>> We would also probably need implementation experience before specifying it</div>
<div>Does that mean you won't help produce a draft spec of this for us to work with?</div><div><br></div><div>> programmers today don'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'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 )\._.,--....,'``. 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. `._.-(,_..'--(,_..'`-.;.'<br>
</font></blockquote></div><br></div>