[whatwg] Global Script proposal.

[Michael Nordman]

These arguments against the proposal are not persuasive. I remain of the
opinion that the GlobalScript proposal has merit.

On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson <ian at hixie.ch> wrote:

> 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.


> we really haven't solved the problem this is setting out to solve

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.


> 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.
>

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.


>
> 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.
>
>
> moving away from single-threaded designs

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.

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.

> old way

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.


> > 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?
>

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.


>
>
> > 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.
>

The key phrase was "directly accessed by the UI"... not possible with 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.
>
>
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.


>
> > 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).
>


You can't rely on opener since it can be closed at any time... including
prior to the openee being loaded.



> > 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.
>

* GlobalScript is a friendlier, easier, more accessible means of
accompishing things

* LocalStorage is acutally persistent which is not want is wanted. Would
need to recognize and ignore stale data.

* PushState is an odd artifact of page-centricity. Its there (partly at
least) to help avoid having to perform frame navigations at all.

Maybe a better approach would be to make frame navigations not so costly.


>
> 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.
>
>
> it would probably belong in its own spec
Maybe this would fit better under the banner of w3c wep apps?

>  We would also probably need implementation experience before specifying
it
Does that mean you won't help produce a draft spec of this for us to work
with?

> programmers today don't want to use threads -- but, well, tough
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.


> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090830/918c3218/attachment-0002.htm>