- From: Michael Nordman <michaeln@google.com>
- Date: Sun, 30 Aug 2009 10:19:16 -0700
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-0001.htm>
Received on Sunday, 30 August 2009 10:19:16 UTC