[whatwg] Global Script proposal.
ian at hixie.ch
Thu Sep 3 04:30:48 PDT 2009
On Sun, 30 Aug 2009, Michael Nordman wrote:
> These arguments against the proposal are not persuasive. I remain of the
> opinion that the GlobalScript proposal has merit.
That's possible; I would recommend taking up a Global Script proposal in
the public-webapps working group, though, as it is more of a Web App API
type of thing than an HTML5 core feature.
> 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.
> 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
We already have a single global object today, in the world where
independent windows end up with different "global script" objects. It's
the Window object of the opener.
> > 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.
> You can't rely on opener since it can be closed at any time... including
> prior to the openee being loaded.
It won't get garbage-collected though, so if it's closed, just grab the
"hot" stuff you want over to a new "master" window.
> Maybe a better approach would be to make frame navigations not so
That's up to browser vendors.
> Does that mean you won't help produce a draft spec of this for us to
> work with?
I think it's a bad idea, so no. :-)
On Mon, 31 Aug 2009, Michael Davidson wrote:
> In general, your arguments seem to fall into three categories.
> (Apologies if I'm misrepresenting you by paraphrasing. My intent is
> not to argue against a straw man, but to actually address your
> - People should be writing multi-threaded web apps.
> - UI code can be a small shim, so code sharing can be accomplished
> through shared workers.
> - The async model isn't really that tough.
> For the first, I would argue that the web should progress much like
> desktop apps. Computationally intensive algorithms will be done in a
> background thread, but all UI interaction will continue to be done on
> one thread. This is how desktop apps work. Scalability is accomplished
> by putting different apps on different cores, not by requiring each
> application view to run in its own thread.
That's fine today, but it won't do us much good when we have orders of
magnitude more cores than running applications.
> Finally, I don't think the UI can ever be a simple shim. There's a
> long list of things that have to be in the UI: complex widget
...should be in the browser, not the Web app.
> UI effects
...should be in the CSS, not the script.
> event handling
That's pretty much all that should be in the UI-thread script, and it
should just defer to the workers.
On Mon, 31 Aug 2009, Mike Shaver wrote:
> The multiple server-side processes that end up involved over the course
> of the user's interaction do need to share state with each other, and
> preserving blocking semantics for accessing such state makes the
> programs much simpler to reason about given today's programming
> languages. Is that shared state not what the Global Script Object would
Aren't global script objects supposed to be client-side? I don't see how
they would help with server-side state.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg