[whatwg] Global Script proposal.

On Mon, 17 Aug 2009, Dmitry Titov wrote:
> 
> Currently there is no mechanism to directly share DOM, code and data on 
> the same ui thread across several pages of the web application. 
> Multi-page applications and the sites that navigate from page to page 
> would benefit from having access to a shared "global script context" 
> (naming?) with direct synchronous script access and ability to 
> manipulate DOM.

This feature is of minimal use if there are multiple global objects per 
application. For instance, if each instance of GMail results in a separate 
global object, we really haven't solved the problem this is setting out to 
solve. We can already get a hold of the Window objects of subwindows (e.g. 
for popping out a chat window), which effectively provides a global 
object for those cases, so it's only an interesting proposal if we can 
guarantee global objects to more than just those.

However, we can't. Given that all frames in a browsing context have to be 
on the same thread, regardless of domain, then unless we put all the 
browsing contexts on the same thread, we can't guarantee that all frames 
from the same domain across all browsing contexts will be on the same 
thread.

But further, we actually wouldn't want to anyway. One of the goals of 
having multiple processes is that if one tab crashes, the others don't. We 
wouldn't want one GMail crash to take down all GMail, Google Calendar, 
Google Chat, Google Reader, Google Search, and Google Voice tabs at once, 
not to mention all the blogs that happened to use Google AdSense.

Furthermore, consider performance going forward. CPUs have pretty much 
gotten as fast as they're getting -- all further progress is going to be 
in making multithreaded applications that use as many CPUs as possible. We 
should actively moving away from single-threaded designs towards 
multithreaded designs. A shared global script is firmly in the old way of 
doing things, and won't scale going forward.


> Chat application opens separate window for each conversation. Any opened 
> window may be closed and user expectation is that remaining windows 
> continue to work fine. Loading essentially whole chat application and 
> maintaining data structures (roster) in each window takes a lot of 
> resources and cpu.

Use a shared worker.

I know that some consider the asynchronous interaction with workers to be 
a blocker problem, but I don't really understand why. We already have to 
have asynchronous communication with the server, which holds the roster 
data structure, and so on. What difference does it make if instead of 
talking to the server, you talk to a worker?


> Finance site could open multiple windows to show information about 
> particular stocks. At the same time, each page often includes data-bound 
> UI components reflecting real-time market data, breaking news etc. It is 
> very natural to have a shared context which can be directly accessed by 
> UI on those pages, so only one set of info is maintained.

Again, use a shared worker. The UI side of things can be quite dumb, with 
data pushed to it from a shared worker.


> A game may open multiple windows sharing the same model to provide 
> different views at the game objects (as in flight simulator).

You wouldn't even want the logic (simulator) in this case to be on the 
same thread as the renderers. In fact ideally you'd want everything on a 
different thread so that you got the best performance out of the system 
-- each renderer, each simulator, etc.


> In an email application, a user may want to open a separate "compose" 
> window for a new email, often after she started to "answer in place" but 
> realized she'd like to look up something else in the mailbox for the 
> answer. This could be an instantaneous operation if the whole html tree 
> and the compose editor script were shared.

This is possible without a shared global script -- it's possible now, in 
fact. Just open a window, and graft the DOM tree from the original window 
into the new window.


> Such multiple-window use cases could be simpler and use much less 
> resources if they had access to a shared Global Script Context so there 
> is no need to re-initialize and maintain the same state in all the 
> pages. Having direct, same-thread DOM/JS access to this context makes it 
> possible to avoid loading and initialization of repetitive code and 
> data, makes separate 'UI windows' simpler and independent.

There's no need for this case to use shared _global_ script; a shared 
script just between the original window and the popped-out window is 
sufficient (and already supported).


> Another case is an application that uses navigation from page to page using
> menu or some site navigation mechanism. Global Script Context could keep the
> application state so it doesn't have to be round-tripped via server in a
> cookie or URL.

You can keep the state using sessionStorage or localStorage, or you can 
use pushState() instead of actual navigation.



I haven't added the Global Script Object proposal to HTML5. Even if we 
were to add it to the platform, it would probably belong in its own 
specification rather than in the HTML spec. We would also probably need 
implementation experience before specifying it. But I really don't think 
it is the direction we should be taking the platform in. Granted, 
programmers today don't want to use threads -- but, well, tough. All 
indications are that that's what the programming model of the next few 
decades is going to be; now is the time to move that way. We shouldn't be 
adding features that actually move us back to the single-threaded world.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 29 August 2009 14:40:29 UTC