W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2009

[whatwg] Global Script proposal.

From: Dmitry Titov <dimich@chromium.org>
Date: Sun, 30 Aug 2009 16:46:52 -0700
Message-ID: <28040fc60908301646v205a8034i2798df48e6731870@mail.gmail.com>
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.


I think you assume some specifics... Lets say there is only 1 "GMail window"
and a couple of 'compose message' ones - the proposal surely helps this
scenario. It also helps the GMail window to navigate between its own views.
Running multiple "GMail windows" may in fact be considering running 2 "GMail
applications" in which case having separate context for them might be even
desirable.



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


The proposal says keep the global object across navigation in the same
browsing context. Also, it provides lifetime of the global context that is
not limited by the lifetime of one of the windows. That is useful and not
possible today.



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

GMail, Calendar and Reader are currently very separate applications on
separate origins. Popup chat windows will be killed today if their opener
(GMail window) crashes. Worse, they will be killed even if the opener will
be closed - since they are on life support from it - and windows get closed
way more often then crashing. Proposal addresses that.

I'm not sure there is, in fact, a deep technical reason behind some apps
existing in a shared origin like www.google.com. It might improve efficiency
of some parts of Google infrastructure, but even if it is, it looks like
Google is a special case, and we should not design API for the way Google
does things currently. There should be ways to tell that specific set of
pages form an "application". Current way to do that, judging from the spec,
is same-origin policy - since many decisions are made on such grouping.
Whether or not more granular grouping of pages into "applications" is needed
remains to be seen (implementation experiment?)



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

Indeed, this proposal has nothing to do with promoting some sort of parallel
computations or multi-threading. I'm also not convinced everything which is
not multi-threaded is firmly the old way :-) As a member of the team that
brought some features to WebKit workers, made workers work in Chrome and is
bringing Shared workers to both, I surely can sympathize with looking at
multi-threading as a proverbial hammer :-) but it doesn't look like
everything can be done with it.

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


Global Script is more of the 'shared library' then a 'server' Again,
academically there is no difference. Practically, there is. For example, UI
frameworks, like Closure, can be shared across pages - multiple and well as
successive, as in navigation from one to another. By not sharing them today,
we make ever-faster JS engines to run ever-growing amounts of JS, spending
memory, battery power and increasing latencies. It is not practical to share
a UI framework in a worker because there are too many of event handlers and
bound UI elements that are directly updated by such frameworks. Instead,
sharing a library in a global script makes it possible to reduce the amount
of script loaded into a popup chat window from 0.5Mb to a few kb - that is
too big win to pass. We have fast CPUs and gigabytes of ram though the
shared libraries are still a good idea.

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


that is what GMail is doing today - but you still have that "progress
indicator" before the new compositing window foes live - and if you close
the 'opener' window while it happens (too often that takes a long time), you
likely loose the half-constructed message. So we sat with GMail guys and
came up with Global Script idea. In fact, those 'tear-offs' are a paint
point exactly because they effectively have to load/start the whole "GMail
application" to become independent from the 'opener'.

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


Not sufficient - because of the artificial requirement to keep one of the
windows open all the time - which is unnatural for the users who usually
treat windows of the same site as 'peers'.

I do agree that experience of practical implementation would be very
valuable here.

Dmitry
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090830/cb5c1932/attachment-0001.htm>
Received on Sunday, 30 August 2009 16:46:52 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:16 UTC