[whatwg] Global Script proposal.

I'm finding it hard to envision the kind of applications that are going to
be created that will need to take advantage of multiple cores when there are
"orders of magnitude more cores than applications". Do you believe that
we're going to see a fundamental shift in the kinds of things people are
going to want to do with computers, away from the typical communication,
data manipulation applications into something else? I think the whole
we-need-to-make-sure-we-can-handle-hundreds-of-cores argument is, frankly,
ridiculous, no offense intended.
On balance, applications tend to be fundamentally simple things, with most
of the complexity being in the creation of the UI, ensuring the user is
guided through the application properly by updating various bits of the UI
at appropriate times, and correcting bad user input. When you get into
applications that do use multiple threads, they generally use multiple
threads with shared memory, not message passing as is envisioned with shared
workers. There are certainly classes of applications that are well suited to
message-passing models, but for those that are user-facing non-server
applications I'd be shocked if anyone could show me data that says more than
10% of the multi-threaded/multi-process applications use isolated tasks that
pass messages to coordinate.

With regard to using the top window as a global context and copying the
relevant bits into another window:

1. many browsers forcibly garbage collect the context when you close a
window, so you can't leave *anything* behind
2. that's a whole lot of stuff you have to copy over, including rebinding
any event handlers in the DOM that are bound to functions loaded in the
closing window. It's impractical.

a

On Thu, Sep 3, 2009 at 4:30 AM, Ian Hickson <ian at hixie.ch> wrote:

> 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
> > feature.
>
> 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
> > costly.
>
> 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
> > concerns.)
> >
> > - 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
> > rendering
>
> ...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
> > provide?
>
> 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.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
Adam de Boor
Google
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090903/81086236/attachment-0001.htm>

Received on Thursday, 3 September 2009 09:58:34 UTC