Re: [whatwg] Global Script proposal.
Commenting in general on this (and not specifically the GlobalScript proposal), I think the outcome of discussions on this list too often is solve it with a single-page Ajax app. In contrast, I think HTML5 should address the needs of multi-page (including all server-side oriented) apps with at least equal weight as the Ajaxy ones. Best regards Mike Wilson Michael Nordman wrote: Agree very much so. On Tue, Sep 15, 2009 at 5:54 PM, Dmitry Titov dim...@chromium.org wrote: it is also an overkill to say that every app should necessarily be a single complex AJAX page morphing itself. That in itself may be a serious limitation.
Re: [whatwg] Global Script proposal.
On Mon, Sep 14, 2009 at 4:41 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 7 Sep 2009, Dimitri Glazkov wrote: On Sat, Aug 29, 2009 at 2:40 PM, Ian Hicksoni...@hixie.ch wrote: 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. First off, sessionStorage and localStorage are not anywhere close to being useful if you're dealing with the actual DOM objects. The JS code that would freeze-dry them and bring back to life will make the whole exercise cost-prohibitive. Indeed. I don't see why you would want to be keeping nodes alive while navigating to entirely new documents though. But more to the point, I think globalScript is a good replacement for the pushState additions to the History spec. I've been reading up on the spec an the comments made about pushState and I am becoming somewhat convinced that pushState is confusing, hard to get right, and full of fail. You should simply look at the motivation behind building JS-based history state managers -- it all becomes fairly clear. The best analogy I can muster is this: pushHistory is like creating Rhoad's-like kinetic machines for moving furniture around the house in an effort to keep the tenant standing still. Whereas globalScript proposes to just let the poor slob to walk to the chest to get the damn socks. My big issue with pushHistory is that it messes with the nature of the Web: a URL is a resource you request from the server. Not something you arrive to via clever sleight of hand in a user agent. So, you've managed to pushState your way to a.com/some/path/10/clicks/from/the/home/page. Now the user bookmarks it. What are you going to do know? Intuitively, it feels like we should be improving the user agent to eliminate the need for mucking with history, not providing more tools to encourage it. The only criticism of substance in the above -- that pushState() lets you change the URL of the current page when you change the page dynamically -- is pretty much the entire point of the feature, and I don't understand why it's bad. I certainly don't want to require that every pan on Google Maps require a new page load. On Tue, 8 Sep 2009, Anne van Kesteren wrote: If JavaScript can be somehow kept-alive while navigating to a new page within a single domain, be in control of what is displayed and without security issues and all that'd be rather cool and also solve the issue. This seems substantially less preferable, performance-wise, than having a single Document and script, using pushState(). It depends, right? That single Document+script would have to have all the resources and code to be able to morph itself into all the possible app states, preventing benefits of lazy-loading. Or, to be more efficient, it should load additional resources on demand, which looks very close to navigation to subsequent pages. Today, those natural navigations from page to page are prohibitively expensive, even with caches - they are equivalent to serialization of everything into some storage, terminating the app, then launching the app again, loading state from storage and/or cloud, setting up the UI etc. So AJAX is the only real alternative today, although it comes with complex pages that have to construct UI dynamically. History management API is great, but it is also an overkill to say that every app should necessarily be a single complex AJAX page morphing itself. That in itself may be a serious limitation.
Re: [whatwg] Global Script proposal.
to say that every app should necessarily be a single complex AJAX page morphing itself. That in itself may be a serious limitation. Agree very much so. On Tue, Sep 15, 2009 at 5:54 PM, Dmitry Titov dim...@chromium.org wrote: On Mon, Sep 14, 2009 at 4:41 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 7 Sep 2009, Dimitri Glazkov wrote: On Sat, Aug 29, 2009 at 2:40 PM, Ian Hicksoni...@hixie.ch wrote: 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. First off, sessionStorage and localStorage are not anywhere close to being useful if you're dealing with the actual DOM objects. The JS code that would freeze-dry them and bring back to life will make the whole exercise cost-prohibitive. Indeed. I don't see why you would want to be keeping nodes alive while navigating to entirely new documents though. But more to the point, I think globalScript is a good replacement for the pushState additions to the History spec. I've been reading up on the spec an the comments made about pushState and I am becoming somewhat convinced that pushState is confusing, hard to get right, and full of fail. You should simply look at the motivation behind building JS-based history state managers -- it all becomes fairly clear. The best analogy I can muster is this: pushHistory is like creating Rhoad's-like kinetic machines for moving furniture around the house in an effort to keep the tenant standing still. Whereas globalScript proposes to just let the poor slob to walk to the chest to get the damn socks. My big issue with pushHistory is that it messes with the nature of the Web: a URL is a resource you request from the server. Not something you arrive to via clever sleight of hand in a user agent. So, you've managed to pushState your way to a.com/some/path/10/clicks/from/the/home/page. Now the user bookmarks it. What are you going to do know? Intuitively, it feels like we should be improving the user agent to eliminate the need for mucking with history, not providing more tools to encourage it. The only criticism of substance in the above -- that pushState() lets you change the URL of the current page when you change the page dynamically -- is pretty much the entire point of the feature, and I don't understand why it's bad. I certainly don't want to require that every pan on Google Maps require a new page load. On Tue, 8 Sep 2009, Anne van Kesteren wrote: If JavaScript can be somehow kept-alive while navigating to a new page within a single domain, be in control of what is displayed and without security issues and all that'd be rather cool and also solve the issue. This seems substantially less preferable, performance-wise, than having a single Document and script, using pushState(). It depends, right? That single Document+script would have to have all the resources and code to be able to morph itself into all the possible app states, preventing benefits of lazy-loading. Or, to be more efficient, it should load additional resources on demand, which looks very close to navigation to subsequent pages. Today, those natural navigations from page to page are prohibitively expensive, even with caches - they are equivalent to serialization of everything into some storage, terminating the app, then launching the app again, loading state from storage and/or cloud, setting up the UI etc. So AJAX is the only real alternative today, although it comes with complex pages that have to construct UI dynamically. History management API is great, but it is also an overkill to say that every app should necessarily be a single complex AJAX page morphing itself. That in itself may be a serious limitation.
Re: [whatwg] Global Script proposal.
On Mon, 7 Sep 2009, Dimitri Glazkov wrote: On Sat, Aug 29, 2009 at 2:40 PM, Ian Hicksoni...@hixie.ch wrote: 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. First off, sessionStorage and localStorage are not anywhere close to being useful if you're dealing with the actual DOM objects. The JS code that would freeze-dry them and bring back to life will make the whole exercise cost-prohibitive. Indeed. I don't see why you would want to be keeping nodes alive while navigating to entirely new documents though. But more to the point, I think globalScript is a good replacement for the pushState additions to the History spec. I've been reading up on the spec an the comments made about pushState and I am becoming somewhat convinced that pushState is confusing, hard to get right, and full of fail. You should simply look at the motivation behind building JS-based history state managers -- it all becomes fairly clear. The best analogy I can muster is this: pushHistory is like creating Rhoad's-like kinetic machines for moving furniture around the house in an effort to keep the tenant standing still. Whereas globalScript proposes to just let the poor slob to walk to the chest to get the damn socks. My big issue with pushHistory is that it messes with the nature of the Web: a URL is a resource you request from the server. Not something you arrive to via clever sleight of hand in a user agent. So, you've managed to pushState your way to a.com/some/path/10/clicks/from/the/home/page. Now the user bookmarks it. What are you going to do know? Intuitively, it feels like we should be improving the user agent to eliminate the need for mucking with history, not providing more tools to encourage it. The only criticism of substance in the above -- that pushState() lets you change the URL of the current page when you change the page dynamically -- is pretty much the entire point of the feature, and I don't understand why it's bad. I certainly don't want to require that every pan on Google Maps require a new page load. On Tue, 8 Sep 2009, Anne van Kesteren wrote: If JavaScript can be somehow kept-alive while navigating to a new page within a single domain, be in control of what is displayed and without security issues and all that'd be rather cool and also solve the issue. This seems substantially less preferable, performance-wise, than having a single Document and script, using pushState(). The pushState() model is basically fixing the AJAX model to work right; it seems like a good thing to me. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Global Script proposal.
On Mon, 07 Sep 2009 23:30:42 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: My big issue with pushHistory is that it messes with the nature of the Web: a URL is a resource you request from the server. Not something you arrive to via clever sleight of hand in a user agent. So, you've managed to pushState your way to a.com/some/path/10/clicks/from/the/home/page. Now the user bookmarks it. What are you going to do know? Intuitively, it feels like we should be improving the user agent to eliminate the need for mucking with history, not providing more tools to encourage it. FWIW, this is why I think pushState is great. If you bookmark it and later visit that page it allows the server to directly give the right content back instead of first loading a page which then fetches additional content based on the fragment identifier. And although disabling JavaScript these days is probably close to a non-starter it would allow you to create interfaces that have the same URL regardless of whether JavaScript is enabled or disabled and still use fancy effects and downloaded content incrementally when JavaScript is enabled. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Global Script proposal.
On Tue, Sep 8, 2009 at 6:12 AM, Anne van Kesterenann...@opera.com wrote: FWIW, this is why I think pushState is great. If you bookmark it and later visit that page it allows the server to directly give the right content back instead of first loading a page which then fetches additional content based on the fragment identifier. And although disabling JavaScript these days is probably close to a non-starter it would allow you to create interfaces that have the same URL regardless of whether JavaScript is enabled or disabled and still use fancy effects and downloaded content incrementally when JavaScript is enabled. True, that's a benefit -- compared to the current hash-navigation systems. But I guess what I am trying to say is let's work to provide ways to make navigation cheap, rather than improving ways to simulate navigation. :DG
Re: [whatwg] Global Script proposal.
On Tue, 08 Sep 2009 17:57:36 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, Sep 8, 2009 at 6:12 AM, Anne van Kesterenann...@opera.com wrote: FWIW, this is why I think pushState is great. If you bookmark it and later visit that page it allows the server to directly give the right content back instead of first loading a page which then fetches additional content based on the fragment identifier. And although disabling JavaScript these days is probably close to a non-starter it would allow you to create interfaces that have the same URL regardless of whether JavaScript is enabled or disabled and still use fancy effects and downloaded content incrementally when JavaScript is enabled. True, that's a benefit -- compared to the current hash-navigation systems. But I guess what I am trying to say is let's work to provide ways to make navigation cheap, rather than improving ways to simulate navigation. Yeah, your follow-up message in the separate thread sounded rather intriguing. If JavaScript can be somehow kept-alive while navigating to a new page within a single domain, be in control of what is displayed and without security issues and all that'd be rather cool and also solve the issue. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Global Script proposal.
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 i...@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
Re: [whatwg] Global Script proposal.
On Thu, Sep 3, 2009 at 7:30 AM, Ian Hicksoni...@hixie.ch wrote: 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. Yeah, I was reasoning by analogy; the global script object would on the client be used as the databases or session state are on the server side. (Especially since LocalStorage isn't available to workers.) Mike
Re: [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 i...@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 i...@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
Re: [whatwg] Global Script proposal.
Ian Hickson wrote: 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. Right, the GlobalScript proposal would cause an additional vector that enlarges the sets of related similar-origin browsing contexts, ie making more browsing contexts share event loop. But there are already a number of relationships that cause this, so can we really say that having one more is not possible? As an application developer I wouldn't have any problem with knowing up-front that my application would share thread with the other instances (pages) of my application if I use the GlobalScipt feature. (And has been mentioned, it wouldn't be a forced requirement.) @Dmitry: as an implementor, do you find problems with having a loaded page change event loop and thread, or is that just about swapping around data structures? What I'm thinking about is that if swapping is possible, then every page can start on its own thread, and then only swap over to the shared thread for that unit of related similar-origin browsing contexts if referencing a GlobalScript. (If swapping is not possible, then every page would have to try to join the thread for its origin at load time, to be prepared for GlobalScript sharing, and that would probably pull together more browsing contexts than desired into shared threds...) [...] 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. FWIW, I don't see the GlobalScript proposal as something that wants to avoid multi-threading. Though, with JavaScript's shared nothing approach between threads, single-threading is a side-effect of having live access (no intermediate serializing/cloning) to shared data. If there was multi-threaded access to data (you could say there already is with cookies and the storage mutex) I'm sure the GlobalScript proposal could be tailored to take advantage of that. Best regards Mike
Re: [whatwg] Global Script proposal.
(Grabbing from the end...) On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson i...@hixie.ch wrote: 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. Shared workers aren't analogous to a multithreaded programming model. They're a multiple-single-threaded-process model. It makes a difference. The former is familiar to many programmers. The latter is much less common. 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. The application itself can decide how best to take advantage of multiple cores, balancing coding complexity against performance. This is how I'd like to see web apps work. Sharing data should be separate from splitting across cores. If an app needs to push computation to a worker thread, that facility is available, but it should be up to the app. (Of course, computationally intensive desktop applications have access to a shared heap, which would make shared workers much more attractive.) For the last two, I don't believe that they can be true simultaneously. 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? It is true that XHRs to the server are async. If shared workers simply replace the server, then it's true, programming that way is exactly what people are used to. However, under that model pages that access the shared worker have all the complex code that they have today. If the shared worker replaces a server, then the worker is adding code to the client, not replacing it. For the UI to be a simple shim, shared workers have to replace more than just the server. They have to encompass the entire data model of the application. Pushing the async line from network I/O up to the data layer of the app is a huge change. I am unaware of any programming frameworks that work this way. It's not just that this is a difficult way to program, it's entirely new. You have said previously that having to rewrite Gmail is not justification for a feature, and I agree. However, since this is a totally different programming model, I find it unlikely that weekend coding projects will start off taking advantage of shared workers in a way that will maximize code reuse. Since almost all web apps start as weekend coding projects, by the time they get big enough to require code sharing, synchronous access to the data model from the UI will be endemic to the app, and it will require a rewrite. It seems to me that having shared workers as the only mechanism for code sharing is going to require a rewrite of nearly every web app, even those written in the future. (It's possible that frameworks will evolve to encourage async programming to the data model like they currently do to the network, but they will all require a rewrite before that happens.) Again, use a shared worker. The UI side of things can be quite dumb, with data pushed to it from a shared worker. 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, UI effects, event handling, etc. Popular frameworks like jQuery have huge amounts of code dedicated to UI programming. It's not possible to push this code to a shared worker. Every render process will have to have its own copy. Especially if the shared worker is more than just a local cache for the server, the UI layer will always be complex. Michael
Re: [whatwg] Global Script proposal.
On Sat, Aug 29, 2009 at 5:40 PM, Ian Hicksoni...@hixie.ch wrote: 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. Multi-threaded or multi-process, at least. Most web developers are quite familiar with multi-process development, where each process has a single flow of control, since that's what the browser/server interaction is. 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? If the synchronization overhead of manipulating it becomes undesirable to an app developer for performance reasons, they can use a worker with local state and an event mechanism or some such; that's largely what people do on the server side as well. 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. I disagree that explicit use of threads is the programming model of the next few decades. We are seeing more and more developers eschew shared-heap threads in favour of other techniques (f.e., task queues) that adapt better to varying system resources and allow simpler decomposition of the programming tasks. Apple's Grand Central Dispatch appears to be in this vein, though I confess I haven't analyzed it in any significant way yet. Mike
Re: [whatwg] Global Script proposal.
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 i...@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
Re: [whatwg] Global Script proposal.
On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson i...@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
Re: [whatwg] Global Script proposal.
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. 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. 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. 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? 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. 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. 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). 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. I haven't added the Global
Re: [whatwg] Global Script proposal
Patrick Mueller wrote:
Michael Nordman wrote:
I'm confused about the manual loading of the script into the context? The
original proposal called for providing a script url when
creating/connecting
to an instance of a global-script... in which case each client page
expresses something more like...
globalScript = new GlobalScript(scriptUrl);
globalScript.onload = myFunctionThatGetsCalledWhenTheScriptIsLoaded;
// some time later onload fires, if the script was already loaded, its
called on the next time thru the message loop
Here's what Dmitry Titov proposed on 2009/08/17:
var context = new GlobalScript();
context.onload = function () {...}
context.onerror = function () {...}
context.load('foo.js');
Dmitry had a later note which combined creation of the context and
loading of the script. But I suspect one thing people will want to do,
in development anyway, is load multiple scripts into a context - like
you can in workers. Which would mean we'd still need a function to load
a script, or the only way to load a script would be by also creating a
new context - which is much like the serverJS module concept.
--
Patrick Mueller - http://muellerware.org
Re: [whatwg] Global Script proposal
Dmitry had a later note which combined creation of the context and loading of the script. But I suspect one thing people will want to do, in development anyway, is load multiple scripts into a context - like you can in workers. Which would mean we'd still need a function to load a script, or the only way to load a script would be by also creating a new context - which is much like the serverJS module concept. I think the plan is to provide an importScript(...) function to globalScripts as is done for workers... http://www.whatwg.org/specs/web-workers/current-work/#importing-scripts-and-libraries
Re: [whatwg] Global Script proposal
I did mention 2 forms of script load indeed, mostly trying to find a
simplest form that will be also consistent with what's already there in the
spec.
In terms of loading scripts, it seems the GlobalScript is quite similar to
what SharedWorker does to load its scripts.When creating SharedWorker, one
specifies the url right away as a constructor parameter, and this url later
is used to form an ID of the SharedWorker. The load is asynchronous and the
page is registering an event handler to 'hear' from the script when it is
ready. The Worker can, in turn, create 'nested' Workers (async). Also, it
can load more scripts into themselves via importScript(urls) - this time
synchronously (this is rough equivalent of script tag in a JS context).
Note that initial load is different from 'importing' more script - initial
loading is governed by SOP and is async, while the importScript can go
cross-domain, does not create a security context and is synchronous.
Whether or not this is the best possible scheme is a separate topic, but it
seems close enough to what GlobalScript needs so if nothing else,
consistency with this spec might be a good idea.
Dmitry
On Mon, Aug 24, 2009 at 6:05 AM, Patrick Mueller pmue...@muellerware.orgwrote:
Patrick Mueller wrote:
Michael Nordman wrote:
I'm confused about the manual loading of the script into the context? The
original proposal called for providing a script url when
creating/connecting
to an instance of a global-script... in which case each client page
expresses something more like...
globalScript = new GlobalScript(scriptUrl);
globalScript.onload = myFunctionThatGetsCalledWhenTheScriptIsLoaded;
// some time later onload fires, if the script was already loaded, its
called on the next time thru the message loop
Here's what Dmitry Titov proposed on 2009/08/17:
var context = new GlobalScript();
context.onload = function () {...}
context.onerror = function () {...}
context.load('foo.js');
Dmitry had a later note which combined creation of the context and loading
of the script. But I suspect one thing people will want to do, in
development anyway, is load multiple scripts into a context - like you can
in workers. Which would mean we'd still need a function to load a script,
or the only way to load a script would be by also creating a new context -
which is much like the serverJS module concept.
--
Patrick Mueller - http://muellerware.org
Re: [whatwg] Global Script proposal
BTW, the WorkerGlobalScope.importScript() API blocks the current thread of execution, which is probably not acceptable for code executed from page context. So for globalscripts we'll need some way to do async notifications when the loading is complete, and report errors. We may also want to have some way to automatically enforce ordering (so if I call GlobalScript.importScripts() twice in a row, the second script is not executed until after the first script is loaded/executed, to deal with dependencies between scripts). The alternative is to force applications to do their own manual ordering. -atw On Mon, Aug 24, 2009 at 11:32 AM, Michael Nordman micha...@google.comwrote: Dmitry had a later note which combined creation of the context and loading of the script. But I suspect one thing people will want to do, in development anyway, is load multiple scripts into a context - like you can in workers. Which would mean we'd still need a function to load a script, or the only way to load a script would be by also creating a new context - which is much like the serverJS module concept. I think the plan is to provide an importScript(...) function to globalScripts as is done for workers... http://www.whatwg.org/specs/web-workers/current-work/#importing-scripts-and-libraries
Re: [whatwg] Global Script proposal
Agreed, blocking semantics are definitely not OK for GlobalScript, this context-type calls for some form of async importScript functionality. If order load order matters, apps certainly could defer loading the scripts until what they depend on have been already loaded already. Where load order doesn't matter, seems unfortunate to penalize those callers. Maybe importScripts(['one.js', 'two.js'], onloadcallback, onerrorcallback); Immediately initiates in-order loading of the given array of resources. A second call to importScripts would also begin immediately as well. So if order matters, put them in the same importScripts call, and if it doesn't make individual calls. On Mon, Aug 24, 2009 at 3:15 PM, Drew Wilson atwil...@google.com wrote: BTW, the WorkerGlobalScope.importScript() API blocks the current thread of execution, which is probably not acceptable for code executed from page context. So for globalscripts we'll need some way to do async notifications when the loading is complete, and report errors. We may also want to have some way to automatically enforce ordering (so if I call GlobalScript.importScripts() twice in a row, the second script is not executed until after the first script is loaded/executed, to deal with dependencies between scripts). The alternative is to force applications to do their own manual ordering. -atw On Mon, Aug 24, 2009 at 11:32 AM, Michael Nordman micha...@google.comwrote: Dmitry had a later note which combined creation of the context and loading of the script. But I suspect one thing people will want to do, in development anyway, is load multiple scripts into a context - like you can in workers. Which would mean we'd still need a function to load a script, or the only way to load a script would be by also creating a new context - which is much like the serverJS module concept. I think the plan is to provide an importScript(...) function to globalScripts as is done for workers... http://www.whatwg.org/specs/web-workers/current-work/#importing-scripts-and-libraries
Re: [whatwg] Global Script proposal
Patrick Mueller wrote:
Time to work on some examples. This would relatively easy to prototype
in something like Rhino (or my nitro_pie python wrapper for
JavaScriptCore), at least API wise, so we could see what the user-land
code would look like, and see it run.
I developed a simulator for this yesterday. My big take away is that
the current shape leaves users in a batteries-not-included state.
Here's the kind of code I had to write to arrange to create a new scope
and load a single script in it from multiple windows. Each window would
run this code in it's own context.
function loadLibrary(scopeName, script, callback) {
var scope = getSharedScope(scopeName);
// script already loaded in the scope
if (scope.__loaded) {
callback(scope, scope.__callback_data);
}
// script not yet done loading
else if (scope.__loading) {
scope.__onLoadedListeners.push(callback);
}
// first one in! much work to do ...
else {
scope.__loading = true;
scope.__onLoadedListeners = [];
function handler(callback_data) {
scope.__loaded= true;
scope.__loading = false;
scope.__callback_data = callback_data;
callback(scope, callback_data);
for (var i=0; iscope.__onLoadedListeners.length; i++) {
scope.__onLoadedListeners[i](scope, callback_data);
}
}
scope.runScript(script, {handler: handler});
}
return scope;
}
I changed the GlobalScript() constructor to a getSharedScope() function
(at the top), and the load() function to a runScript() function which
takes parameters including a callback function.
I'm of two minds here.
One is that the SharedScope proposal is really only appropriate for
pages with lots of JavaScript that could be shared, or special use cases
where you want (eventually) easy sharing between windows. As such, s
smallish amount of JS framework-y-ness like this isn't a show stopper.
In fact, as spec'd, separating out the scope and script loading, will
let folks build mini-frameworks for themselves fairly easily, customized
to their own needs.
On the other hand, I wonder about the potential benefits of letting more
people play in the space easier. The securable module work in the
serverjs projects it a bit easier to use out of the box. I'm not sure
they have an async story though, and async loading of scripts is where
this stuff quickly gets complicated.
--
Patrick Mueller - http://muellerware.org
Re: [whatwg] Global Script proposal.
Mike Wilson wrote: Another thing: From the proposal it seems it will be possible for the GlobalScript context to keep references to objects (DOM, JS data, etc) private to pages, and vice versa possible for pages to keep references to GlobalScript objects. This also opens up for a new way for independent pages finding and keeping references to each other's objects if they are somehow registered in the GlobalScript. When reloading a page there is also the additional dimension of the GlobalScript possibly holding references to objects both from the previous and current incarnation of the Document. In a way it seems GlobalScript usage will in practice merge the JS worlds of all participating pages, potentially including those already navigated away from. What are your thoughts on this? You could either force people to clean up after themselves, or they'll just be accumulating (essentially) garbage. Or you could imagine for contexts that have gone away (windows closed), the references to objects in those contexts magically become null. The second approach requires something like Smalltalk's become: method, at the JS engine level. And then folks might want to start asking for weak references, etc. Slippery slope to hell. Another issue with the merge of JS worlds, which by the way is something which is done explicitly, not implicitly, will lead to potential version mis-match issues. Two pages accessing the same space may have different expectations of the versions of code loaded in them. This could be mitigated by using a version number in the space name, but that leads to a nightmare if you have lots of these spaces, having to apply version numbering for every change to your code. Java developers have a similar problem they affectionately call ClassLoader hell. -- Patrick Mueller - http://muellerware.org
Re: [whatwg] Global Script proposal.
On Fri, Aug 21, 2009 at 4:50 AM, Mike Wilsonmike...@hotmail.com wrote: Another thing: From the proposal it seems it will be possible for the GlobalScript context to keep references to objects (DOM, JS data, etc) private to pages, and vice versa possible for pages to keep references to GlobalScript objects. This also opens up for a new way for independent pages finding and keeping references to each other's objects if they are somehow registered in the GlobalScript. When reloading a page there is also the additional dimension of the GlobalScript possibly holding references to objects both from the previous and current incarnation of the Document. In a way it seems GlobalScript usage will in practice merge the JS worlds of all participating pages, potentially including those already navigated away from. What are your thoughts on this? Don't all of these problems already exist with window.open() and frames? Can the existing solutions not be reused? - a
Re: [whatwg] Global Script proposal.
On Fri, Aug 21, 2009 at 11:10 AM, Aaron Boodman a...@google.com wrote: On Fri, Aug 21, 2009 at 4:50 AM, Mike Wilsonmike...@hotmail.com wrote: Another thing: From the proposal it seems it will be possible for the GlobalScript context to keep references to objects (DOM, JS data, etc) private to pages, and vice versa possible for pages to keep references to GlobalScript objects. This also opens up for a new way for independent pages finding and keeping references to each other's objects if they are somehow registered in the GlobalScript. When reloading a page there is also the additional dimension of the GlobalScript possibly holding references to objects both from the previous and current incarnation of the Document. In a way it seems GlobalScript usage will in practice merge the JS worlds of all participating pages, potentially including those already navigated away from. What are your thoughts on this? Don't all of these problems already exist with window.open() and frames? Can the existing solutions not be reused? It does look similar, so same methods could be used. One idea which was mentioned (and seems like nice to have) is to have a couple of events exposed to the GlobalScript global scope, 'connected' and 'disconnected' which would fire when a page connects to a GlobalScript and right after it is closed (so it 'disconnects' from it). This can help with housekeeping, although more thought should go into defining those, their parameters etc. Dmitry
Re: [whatwg] Global Script proposal
On Fri, Aug 21, 2009 at 6:37 AM, Patrick Mueller pmue...@muellerware.orgwrote:
Patrick Mueller wrote:
Time to work on some examples. This would relatively easy to prototype in
something like Rhino (or my nitro_pie python wrapper for JavaScriptCore), at
least API wise, so we could see what the user-land code would look like, and
see it run.
I developed a simulator for this yesterday. My big take away is that the
current shape leaves users in a batteries-not-included state.
Here's the kind of code I had to write to arrange to create a new scope and
load a single script in it from multiple windows. Each window would run
this code in it's own context.
function loadLibrary(scopeName, script, callback) {
var scope = getSharedScope(scopeName);
// script already loaded in the scope
if (scope.__loaded) {
callback(scope, scope.__callback_data);
}
// script not yet done loading
else if (scope.__loading) {
scope.__onLoadedListeners.push(callback);
}
// first one in! much work to do ...
else {
scope.__loading = true;
scope.__onLoadedListeners = [];
function handler(callback_data) {
scope.__loaded= true;
scope.__loading = false;
scope.__callback_data = callback_data;
callback(scope, callback_data);
for (var i=0; iscope.__onLoadedListeners.length; i++) {
scope.__onLoadedListeners[i](scope, callback_data);
}
}
scope.runScript(script, {handler: handler});
}
return scope;
}
I changed the GlobalScript() constructor to a getSharedScope() function (at
the top), and the load() function to a runScript() function which takes
parameters including a callback function.
I'm of two minds here.
One is that the SharedScope proposal is really only appropriate for pages
with lots of JavaScript that could be shared, or special use cases where you
want (eventually) easy sharing between windows. As such, s smallish amount
of JS framework-y-ness like this isn't a show stopper. In fact, as spec'd,
separating out the scope and script loading, will let folks build
mini-frameworks for themselves fairly easily, customized to their own needs.
On the other hand, I wonder about the potential benefits of letting more
people play in the space easier. The securable module work in the serverjs
projects it a bit easier to use out of the box. I'm not sure they have an
async story though, and async loading of scripts is where this stuff quickly
gets complicated.
For a feature of this scope, I think it's much better to keep the API
surface area as low as is possible for the first version. If, out of the
frameworks, emerges a clear winner, then we should talk about expanding the
API. Until then, I worry we'll just be speculating/bike-shedding.
Thanks for doing this, btw!
J
Re: [whatwg] Global Script proposal
I'm confused about the manual loading of the script into the context? The
original proposal called for providing a script url when creating/connecting
to an instance of a global-script... in which case each client page
expresses something more like...
globalScript = new GlobalScript(scriptUrl);
globalScript.onload = myFunctionThatGetsCalledWhenTheScriptIsLoaded;
// some time later onload fires, if the script was already loaded, its
called on the next time thru the message loop
... the system (not the client pages) keep track of how many client pages
are concurrently accessing the same GlobalScript.
On Fri, Aug 21, 2009 at 6:37 AM, Patrick Mueller pmue...@muellerware.orgwrote:
Patrick Mueller wrote:
Time to work on some examples. This would relatively easy to prototype in
something like Rhino (or my nitro_pie python wrapper for JavaScriptCore), at
least API wise, so we could see what the user-land code would look like, and
see it run.
I developed a simulator for this yesterday. My big take away is that the
current shape leaves users in a batteries-not-included state.
Here's the kind of code I had to write to arrange to create a new scope and
load a single script in it from multiple windows. Each window would run
this code in it's own context.
function loadLibrary(scopeName, script, callback) {
var scope = getSharedScope(scopeName);
// script already loaded in the scope
if (scope.__loaded) {
callback(scope, scope.__callback_data);
}
// script not yet done loading
else if (scope.__loading) {
scope.__onLoadedListeners.push(callback);
}
// first one in! much work to do ...
else {
scope.__loading = true;
scope.__onLoadedListeners = [];
function handler(callback_data) {
scope.__loaded= true;
scope.__loading = false;
scope.__callback_data = callback_data;
callback(scope, callback_data);
for (var i=0; iscope.__onLoadedListeners.length; i++) {
scope.__onLoadedListeners[i](scope, callback_data);
}
}
scope.runScript(script, {handler: handler});
}
return scope;
}
I changed the GlobalScript() constructor to a getSharedScope() function (at
the top), and the load() function to a runScript() function which takes
parameters including a callback function.
I'm of two minds here.
One is that the SharedScope proposal is really only appropriate for pages
with lots of JavaScript that could be shared, or special use cases where you
want (eventually) easy sharing between windows. As such, s smallish amount
of JS framework-y-ness like this isn't a show stopper. In fact, as spec'd,
separating out the scope and script loading, will let folks build
mini-frameworks for themselves fairly easily, customized to their own needs.
On the other hand, I wonder about the potential benefits of letting more
people play in the space easier. The securable module work in the serverjs
projects it a bit easier to use out of the box. I'm not sure they have an
async story though, and async loading of scripts is where this stuff quickly
gets complicated.
--
Patrick Mueller - http://muellerware.org
Re: [whatwg] Global Script proposal
Hi,
a general comment on the interesting GlobalScript proposal for helping
to structure client-side portions of a web application - have people looked
in detail at existing work experiences made there? Like .NET's AppDomains.
cheers
--sigbjorn (s...@opera.com)
On 8/21/2009 21:47, Michael Nordman wrote:
I'm confused about the manual loading of the script into the context? The
original proposal called for providing a script url when creating/connecting
to an instance of a global-script... in which case each client page
expresses something more like...
globalScript = new GlobalScript(scriptUrl);
globalScript.onload = myFunctionThatGetsCalledWhenTheScriptIsLoaded;
// some time later onload fires, if the script was already loaded, its
called on the next time thru the message loop
... the system (not the client pages) keep track of how many client pages
are concurrently accessing the same GlobalScript.
On Fri, Aug 21, 2009 at 6:37 AM, Patrick Mueller pmue...@muellerware.orgwrote:
Patrick Mueller wrote:
Time to work on some examples. This would relatively easy to prototype in
something like Rhino (or my nitro_pie python wrapper for JavaScriptCore), at
least API wise, so we could see what the user-land code would look like, and
see it run.
I developed a simulator for this yesterday. My big take away is that the
current shape leaves users in a batteries-not-included state.
Here's the kind of code I had to write to arrange to create a new scope and
load a single script in it from multiple windows. Each window would run
this code in it's own context.
function loadLibrary(scopeName, script, callback) {
var scope = getSharedScope(scopeName);
// script already loaded in the scope
if (scope.__loaded) {
callback(scope, scope.__callback_data);
}
// script not yet done loading
else if (scope.__loading) {
scope.__onLoadedListeners.push(callback);
}
// first one in! much work to do ...
else {
scope.__loading = true;
scope.__onLoadedListeners = [];
function handler(callback_data) {
scope.__loaded= true;
scope.__loading = false;
scope.__callback_data = callback_data;
callback(scope, callback_data);
for (var i=0; iscope.__onLoadedListeners.length; i++) {
scope.__onLoadedListeners[i](scope, callback_data);
}
}
scope.runScript(script, {handler: handler});
}
return scope;
}
I changed the GlobalScript() constructor to a getSharedScope() function (at
the top), and the load() function to a runScript() function which takes
parameters including a callback function.
I'm of two minds here.
One is that the SharedScope proposal is really only appropriate for pages
with lots of JavaScript that could be shared, or special use cases where you
want (eventually) easy sharing between windows. As such, s smallish amount
of JS framework-y-ness like this isn't a show stopper. In fact, as spec'd,
separating out the scope and script loading, will let folks build
mini-frameworks for themselves fairly easily, customized to their own needs.
On the other hand, I wonder about the potential benefits of letting more
people play in the space easier. The securable module work in the serverjs
projects it a bit easier to use out of the box. I'm not sure they have an
async story though, and async loading of scripts is where this stuff quickly
gets complicated.
--
Patrick Mueller - http://muellerware.org
Re: [whatwg] Global Script proposal
Michael Nordman wrote:
I'm confused about the manual loading of the script into the context? The
original proposal called for providing a script url when creating/connecting
to an instance of a global-script... in which case each client page
expresses something more like...
globalScript = new GlobalScript(scriptUrl);
globalScript.onload = myFunctionThatGetsCalledWhenTheScriptIsLoaded;
// some time later onload fires, if the script was already loaded, its
called on the next time thru the message loop
Here's what Dmitry Titov proposed on 2009/08/17:
var context = new GlobalScript();
context.onload = function () {...}
context.onerror = function () {...}
context.load('foo.js');
--
Patrick Mueller - http://muellerware.org
Re: [whatwg] Global Script proposal.
Jeremy Orlow wrote: Btw, I thought I'd just point out that the proposal mentions this case: From the proposal text: All pages connected to the same Global Script should run on the same thread, in the same process. Since this is not always technically possible, it should be legal (and not break the applications) for there to be duplicate global script contexts within a UA. I'm glad this came up, however, since now it's more clear why such language is necessary. Ah, right I misread that part. I interpreted the second half of it (after technically possible) as other threading models were possible. Now, as I understand it, two pages sharing a GlobalScript MUST share a single thread, or otherwise MUST use a different/duplicate GlobalScript instance. On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilson mike...@hotmail.com wrote: With this stated, I'd like to throw out a question on what do you want the most - max performance in 100% of cases, but redundant GlobalScript contexts, or max performance in most cases and singular GlobalScript contexts? I don't think any UA is realistically going to do this for v1. But sure, the door should be left open for in the future. (The initial proposal allows for both, btw.) That's exactly my point, the door should be open for these kind of improvements. But to allow both, I think the proposal text has to be adjusted somewhat, as interpretations (like mine) will otherwise risk assuming that different threads/processes MUST imply having different GlobalScript context instances. Best regards Mike
Re: [whatwg] Global Script proposal.
This looks interesting.
Dmitry Titov wrote:
A web page will be able to create a Global Script and connect to it, as in
this example:
var context = new GlobalScript(); // perhaps 'webkitGlobalScript' as
experimental feature?
context.onload = function () {...}
context.onerror = function () {...}
context.load('foo.js');
Presumably this script is being loaded asynchronously, hence the
callbacks. But since the GlobalScript() constructor returns the
global object, probably doesn't make sense to attach the handlers
directly there, but actually on the load request somehow. And
presumably you'd be able to load multiple .js files. This will be
interesting, as the .js files presumably will get interpreted in an
arbitrary order - we'll be inventing some new idioms (not a problem,
just an observation).
Is this then really the only API exposed? A constructor and a js
loader? (+1, less is more)
I guess I'm wondering if there will be some desire to have pages opt-in
to this support, signaling this through an additional API, or like the
app-cache's manifest attribute on the html element, something in the
DOM; doesn't seem like we should drag the DOM in here, just mentioned it
because I was reminded of the way the opt-in works there.
Or perhaps these GlobalScripts - should really be called GlobalObjects
or GlobalContexts maybe; SharedScope? - could be named, by passing a
string on the constructor? Would there be value in having multiple
named scopes available? In the current scenario with a no-arg
constructor, what happens when I invoke it again? If it should return
the same object, then don't use a constructor, use a plain old function
- SharedScope.getCurrent().
--
Patrick Mueller - http://muellerware.org
Re: [whatwg] Global Script proposal.
On Wed, Aug 19, 2009 at 10:48 AM, Dmitry Titov dim...@google.com wrote:
On Wed, Aug 19, 2009 at 7:37 AM, Patrick Mueller
pmue...@muellerware.orgwrote:
var context = new GlobalScript(); // perhaps 'webkitGlobalScript' as
experimental feature?
context.onload = function () {...}
context.onerror = function () {...}
context.load('foo.js');
Presumably this script is being loaded asynchronously, hence the
callbacks. But since the GlobalScript() constructor returns the global
object, probably doesn't make sense to attach the handlers directly there,
but actually on the load request somehow.
Good point. Alternative variant to construction/connection to this object
could be something like this:
window.createGlobalScript('name', 'foo.js', function(context) {..},
function(status) {..});
where the name and url pair play the same role as on SharedWorker, and 2
callbacks: one delivers load status/errors, another comes with resolved
context when it's ready. One benefit of this is that 'context' does not have
to expose the 'external' API on it and it is always functional once it's
returned. The syntax in the proposal was motivated by commonality with other
APIs, like XHR or window.open - however I agree this doesn't fit 100% either
of them...
fyi: There's a seperate thread questioning the utility of the 'name'
parameter in the SharedWorker API. However the debate ends, it would
probably be good to identify shared-workers / global-scripts in a similar
fashion.
I guess I'm wondering if there will be some desire to have pages opt-in to
this support, signaling this through an additional API, or like the
app-cache's manifest attribute on the html element, something in the DOM;
doesn't seem like we should drag the DOM in here, just mentioned it because
I was reminded of the way the opt-in works there.
I don't follow the opt-in desirement? If a page wishes to utilize the
GlobalScript feature, it calls the API provided to do so.
It is a good idea indeed to have some sort of static opt-in information,
maybe via a feature of app-cache - which could hint the UA to load
participating pages (of the same application) into the same process so they
could share Global Script. It is still impossible (and probably not
important) to guarantee a singularity of the Global Script (as in case of
cross-domain iframes) but it'd be a good optimization for a multi-process
UA.
I understand the desire for early warning that a page *may* want to utilized
a GlobalScript. A 'hint' could be useful to a multi-process UA. It's not
clear to me that this is what Patrick was referring to... Patrick?
And I'll just throw out there that a 'hint' in an custom HTTP header of the
page's response would be the earliest warning we could get without static
config info present in the UA. I know Ian doesn't like relying on
out-of-band HTTP things for the HTML5 spec... just sayin...
Dmitry
Re: [whatwg] Global Script proposal.
Patrick Mueller wrote: Or perhaps these GlobalScripts - should really be called GlobalObjects or GlobalContexts maybe; SharedScope? I like Shared as this is the term used in SharedWorkers to identify something that can be shared between multiple pages. SharedContext? Best regards Mike
Re: [whatwg] Global Script proposal.
Michael Nordman wrote: I understand the desire for early warning that a page *may* want to utilized a GlobalScript. A 'hint' could be useful to a multi-process UA. It's not clear to me that this is what Patrick was referring to... Patrick? I wasn't thinking as a hint for the browser, but that's of course a good idea. I was thinking security. Are there cases where I specifically would NOT want to share? If so, the only alternative is to guarantee that no code you ever load will ever try. It would be safer to allow an author to indicate this page must not be shared. Guess that's more of an opt-out. And I don't have a use case for I don't want to share, nor could I claim that even if they didn't want to, it would be unsafe if they did anyway (ie, it might be safe even if they didn't want to share). Just thinking aloud. -- Patrick Mueller - http://muellerware.org
Re: [whatwg] Global Script proposal.
Dmitry Titov wrote: The return value from a constructor is the Global Script's global scope object. It can be used to directly access functions and variables defined in global scope of the Global Script. While this global scope does not have 'window' or 'document' and does not have visual page associated with it, the local storage, database, timers and XHR are exposed to it, and it can build up DOM for the connected pages using their 'document' object. This turns out to be fairly similar to the serverJS concept of modules. I could see how you might want to use it this way, to get script code loaded into it's own sandbox, and allow the client of the module to name the object as they see fit. This would require the use of a name when you create it, so as to allow multiple to be created, and to allow other sharers to find those objects. This also allows folks to programmatically load JS code without having to resort to XHR/eval or adding script nodes to the DOM. Big plus, because those scripts will then be associated with an honest-to-gods name, which will show up in debuggers. And is obviously cleaner than the other techniques. The list of interfaces exposed in the global scope of the Global Script is similar to that of Shared Worker, except message-passing interface. It could also include events fired when a page connects/disconnects to it and before it is terminated. Can I create additional GlobalScript's from within an existing GlobalScript? The load() method is very similar to the worker loadScript() (or whatever) function. Perhaps we should combine them into one API, that allows sync or async in a worker, but only allows async in a GlobalScript. Or at least advises against use of sync. -- Patrick Mueller - http://muellerware.org
Re: [whatwg] Global Script proposal.
On Wed, Aug 19, 2009 at 1:34 PM, Patrick Mueller pmue...@muellerware.orgwrote: Dmitry Titov wrote: The return value from a constructor is the Global Script's global scope object. It can be used to directly access functions and variables defined in global scope of the Global Script. While this global scope does not have 'window' or 'document' and does not have visual page associated with it, the local storage, database, timers and XHR are exposed to it, and it can build up DOM for the connected pages using their 'document' object. This turns out to be fairly similar to the serverJS concept of modules. I could see how you might want to use it this way, to get script code loaded into it's own sandbox, and allow the client of the module to name the object as they see fit. This would require the use of a name when you create it, so as to allow multiple to be created, and to allow other sharers to find those objects. This also allows folks to programmatically load JS code without having to resort to XHR/eval or adding script nodes to the DOM. Big plus, because those scripts will then be associated with an honest-to-gods name, which will show up in debuggers. And is obviously cleaner than the other techniques. The list of interfaces exposed in the global scope of the Global Script is similar to that of Shared Worker, except message-passing interface. It could also include events fired when a page connects/disconnects to it and before it is terminated. Can I create additional GlobalScript's from within an existing GlobalScript? That's a good question... (just having fun... oh the tangled web we weave;) I'm not sure any has thought thru the implications of that, but it's an interesting idea. * An obvious complication is life-cycle management. If GlobalScriptA attaches to GlobalScriptB, when no 'pages' are attached to either, they should be eligible for destruction. * Also about tangled webs... what if A attaches to B, and B attaches to A The load() method is very similar to the worker loadScript() (or whatever) function. Perhaps we should combine them into one API, that allows sync or async in a worker, but only allows async in a GlobalScript. Or at least advises against use of sync. -- Patrick Mueller - http://muellerware.org
Re: [whatwg] Global Script proposal.
Michael Nordman wrote:
On Wed, Aug 19, 2009 at 1:34 PM, Patrick Mueller pmue...@muellerware.orgwrote:
Can I create additional GlobalScript's from within an existing
GlobalScript?
That's a good question...
(just having fun... oh the tangled web we weave;)
I'm not sure any has thought thru the implications of that, but it's an
interesting idea.
* An obvious complication is life-cycle management. If GlobalScriptA
attaches to GlobalScriptB, when no 'pages' are attached to either, they
should be eligible for destruction.
* Also about tangled webs... what if A attaches to B, and B attaches to A
For completeness, folks interested in this proposal should probably
check out the serverJS Securable Module stuff:
https://wiki.mozilla.org/ServerJS/Modules/SecurableModules
There are similarities, and differences:
- In serverJS, modules are identified with a JavaScript resource,
presumably a single one. In Shared Scopes (what I'm going to call
Global Script from here on in), modules are identified with just a name
and code is loaded through a different path. I like the Shared Scopes
version better, more flexible.
- In serverJS, module loading may need to be done in a careful order so
that pre-req modules are loaded before the modules that pre-req them
(ie, require() them). That's because there is code running while the
module is being defined. If we end up having all the shared scopes
available via their name in every shared scope and page that are
attached to each other, I don't think there's a problem. Creating a new
scope is atomic operation, no user-land code runs as a result. No doubt
folks will be writing guarded code to ensure they only load scripts into
a SharedScope once, since the code loading is now a separate issue.
Again, I like the Shared Scopes approach better.
- In serverJS, a module does not export it's global variable to the
client. Instead, when the module code is run, the object which will
eventually be returned from require() is set to the variable exports
in the module code. In Shared Scopes, this additional level of
indirection is not available; global variables set in code run in the
context of the SharedScope are the properties of the object returned
from the SharedScope accessor. In this case, I prefer the serverJS
style. It makes it clear in the module code what you actually want the
client to have access to. It also lets you hide private variables
inside your own global environment, which is visible to no one. The
same way variables are typically hidden in a function closure today.
Imagine, maybe you won't have da funky function wrappers anymore!
(function(){
... my code here
})();
The load() method is very similar to the worker loadScript() (or whatever)
function. Perhaps we should combine them into one API, that allows sync or
async in a worker, but only allows async in a GlobalScript. Or at least
advises against use of sync.
I think the API I was thinking of with workers is
importScripts(url,url,urls). It seems crazy to have different ways to
do basically the same thing, whether you're in a worker or not. There
should probably be one API to load and run a script, that could be
used sync or async (user controlled just like XHR), with callbacks etc.
Time to work on some examples. This would relatively easy to prototype
in something like Rhino (or my nitro_pie python wrapper for
JavaScriptCore), at least API wise, so we could see what the user-land
code would look like, and see it run.
--
Patrick Mueller - http://muellerware.org
Re: [whatwg] Global Script proposal.
This is an interesting suggestion as it isolates the stateful parts from the rest of the previous suggestions. I like state. Here's how I see how it fits inside the big picture: Scope Serialized state Live state - -- user agent WS_localStorage, GlobalScript [2] SharedWorker [1] cookie browsing context WS_sessionStorage- [3] window.name document -plain JS objs [4] history entry History.pushStateplain JS objs [4] [1] Global state can be coordinated by a SharedWorker but it would need to be serialized in postMessage on transfer so that's why I've put it in the serialized column. [2] As I understand it, the new GlobalScript construct is a context that can be shared by all browsing contexts in the user agent. [3] You also mention that the feature could be usable for page-to-page navigation within the same browsing context. It hasn't been suggested yet, but it would be possible to have a variation of GlobalScript that binds to a specific browsing context, analogous to sessionStorage. [4] These plain JavaScript objects indeed live throughout their Document's life, but this lifetime is usually shorter than what the user's perception tells him. Ie, when the user returns to a previous page through the Back button he regards that as the same document, while technically it's usually a new Document, with a freshly created document tree and JavaScript context. Questions - Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Process boundaries: In this past discussion there have been several mentions about having to cluster pages inside the same process if they are to share data. Why is this so, and why can't shared memory or proxied objects be an option for browsers doing process separation? Best regards Mike Wilson From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Dmitry Titov Sent: den 17 augusti 2009 23:38 To: wha...@whatwg.org Subject: [whatwg] Global Script proposal. Dear whatwg, The previous discussion about shared page and persistence has sent us back 'to the drawing board', to think again what is the essence of the feature and what's not important. Talking with web apps developers indicates the most of benefits can be achieved without dangerous background persistence or the difficulty to specify visual aspects of the invisible page. Here is the new proposal. Your feedback is very appreciated. We are thinking about feasibility of doing experimental implementation in WebKit/Chrome. Thanks! - SUMMARY 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 would compliment Shared Workers (http://www.whatwg.org/specs/web-workers/current-work/) by providing a shared script-based context which does not run on a separate thread and can be used directly from the application's pages. USE CASES 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. 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. A game may open multiple windows sharing the same model to provide different views at the game objects (as in flight simulator). 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. 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
Re: [whatwg] Global Script proposal.
On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote: This is an interesting suggestion as it isolates the stateful parts from the rest of the previous suggestions. I like state. Here's how I see how it fits inside the big picture: Scope Serialized state Live state - -- user agent WS_localStorage, GlobalScript [2] SharedWorker [1] cookie browsing context WS_sessionStorage- [3] window.name document -plain JS objs [4] history entry History.pushStateplain JS objs [4] [1] Global state can be coordinated by a SharedWorker but it would need to be serialized in postMessage on transfer so that's why I've put it in the serialized column. [2] As I understand it, the new GlobalScript construct is a context that can be shared by all browsing contexts in the user agent. [3] You also mention that the feature could be usable for page-to-page navigation within the same browsing context. It hasn't been suggested yet, but it would be possible to have a variation of GlobalScript that binds to a specific browsing context, analogous to sessionStorage. [4] These plain JavaScript objects indeed live throughout their Document's life, but this lifetime is usually shorter than what the user's perception tells him. Ie, when the user returns to a previous page through the Back button he regards that as the same document, while technically it's usually a new Document, with a freshly created document tree and JavaScript context. Questions - Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Nominally, they don't. In our design for chrome's multi-process architecture, the global-script would only be shared within a single 'renderer' process (in which all page's, and global-scripts, execute in a single thread). Process boundaries: In this past discussion there have been several mentions about having to cluster pages inside the same process if they are to share data. Why is this so, and why can't shared memory or proxied objects be an option for browsers doing process separation? A multi-process browser vendor probably *could* proxy all script calls to a truely global context across all 'renderers'... but that is not required in the proposal... and is probably even discouraged. One of the motivations for doing this is webapp performance. Proxying all script interactions across the page/context boundary works against that. Also synchronization issues get much more complicated. Implicit in the proposal is that a global-script is very inexpensive to interact with. Best regards Mike Wilson From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Dmitry Titov Sent: den 17 augusti 2009 23:38 To: wha...@whatwg.org Subject: [whatwg] Global Script proposal. Dear whatwg, The previous discussion about shared page and persistence has sent us back 'to the drawing board', to think again what is the essence of the feature and what's not important. Talking with web apps developers indicates the most of benefits can be achieved without dangerous background persistence or the difficulty to specify visual aspects of the invisible page. Here is the new proposal. Your feedback is very appreciated. We are thinking about feasibility of doing experimental implementation in WebKit/Chrome. Thanks! - SUMMARY 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 would compliment Shared Workers (http://www.whatwg.org/specs/web-workers/current-work/) by providing a shared script-based context which does not run on a separate thread and can be used directly from the application's pages. USE CASES 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. 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. A game
Re: [whatwg] Global Script proposal.
On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote: [2] As I understand it, the new GlobalScript construct is a context that can be shared by all browsing contexts in the user agent. It can, but with a caveat: in case of user agents that are multi-process, in some cases there will be more then one Global Script instance. For example, lets say there is a process for the tab opened for site S1 and there is another process with a tab for site S2. if S2 has iframe pointing to S1, the page in that iframe will get a separate instance of the Global Script since it can't access the one which is created for the tab showing S1. It is equivalent to running the same app in different browsers... So it's across browser contexts in the same process. Questions - Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? The Global Script would run on the main thread of the browser - same one where all the JS on visible pages is executing. It can (and should) use Workers to unload work from ui tread but its use cases are all around running synchronously on the same thread as UI pages of the application, so that it's possible to keep event handlers in it or update the shared UI state synchronously (for example, user selects an image in a document - the toolbar buttons with image operations become active). Process boundaries: In this past discussion there have been several mentions about having to cluster pages inside the same process if they are to share data. Why is this so, and why can't shared memory or proxied objects be an option for browsers doing process separation? Since there is a direct JS access to the Global Script on the main thread of the browser, that would require something like synchronous JS IPC. While theoretically possible, it is very complicated to retrofit the existing browsers for that; it can have issues with performance of JS (especially JIT types of JS engines) and it also has disadvantages of any sync API that may block on a remote resource (since another process is independent and may have its own reasons to block).
Re: [whatwg] Global Script proposal.
Michael Nordman wrote: On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote: Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Nominally, they don't. In our design for chrome's multi-process architecture, the global-script would only be shared within a single 'renderer' process (in which all page's, and global-scripts, execute in a single thread). This might not be the same in other browsers. I think you need to define how concurrent access should be handled so it can be applied to f ex a browser using a single process but a thread per top-level window. If I understand correctly it would be something like letting only one thread call inside the GlobalScript context at a time? Process boundaries: In this past discussion there have been several mentions about having to cluster pages inside the same process if they are to share data. Why is this so, and why can't shared memory or proxied objects be an option for browsers doing process separation? A multi-process browser vendor probably *could* proxy all script calls to a truely global context across all 'renderers'... but that is not required in the proposal... and is probably even discouraged. One of the motivations for doing this is webapp performance. Proxying all script interactions across the page/context boundary works against that. Also synchronization issues get much more complicated. Implicit in the proposal is that a global-script is very inexpensive to interact with. Certainly, the ideal case is that they are in the same process. Using proxies is coming back to serialization all over again, although transparent. What I was commenting was the (seemingly widespread) notion that it is impossible to share data between process, which is not true. There is nothing stopping an implementation from using direct calls whenever process sharing is possible, and falling back to proxies in cases when processes need to be different. With this stated, I'd like to throw out a question on what do you want the most - max performance in 100% of cases, but redundant GlobalScript contexts, or max performance in most cases and singular GlobalScript contexts? Also, what about shared memory (I'm assuming everybody knows what this is) - apart from being non-trivial stuff, are there any specific drawbacks that renders it not useful for this case? Best regards Mike
Re: [whatwg] Global Script proposal.
On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilsonmike...@hotmail.com wrote: Michael Nordman wrote: On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote: Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Nominally, they don't. In our design for chrome's multi-process architecture, the global-script would only be shared within a single 'renderer' process (in which all page's, and global-scripts, execute in a single thread). This might not be the same in other browsers. I think you need to define how concurrent access should be handled so it can be applied to f ex a browser using a single process but a thread per top-level window. If I understand correctly it would be something like letting only one thread call inside the GlobalScript context at a time? I think it is likely impractical for windows that have javascript access to each other to be on separate threads. The relationship between the global script and pages accessing it is similar to a parent windows and an iframe that are on the same origin, or to a window and a popup window on the same origin. Objects should be able to be freely passed across both sides. For example, the global script should be able to have a JavaScript object graph which represents some application state and share it (by reference) with its clients. I don't see how it is realistic to do this when the windows are separated by a thread boundary. Therefore, I would say it is totally valid for a UA to put a bunch of windows that want to use the same global script URL in different threads, but it should group them by thread. Each thread should get its own global script that is shared among the windows that are on that thread. - a
Re: [whatwg] Global Script proposal.
On Tue, Aug 18, 2009 at 12:32 PM, Aaron Boodman a...@google.com wrote: On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilsonmike...@hotmail.com wrote: Michael Nordman wrote: On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote: Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Nominally, they don't. In our design for chrome's multi-process architecture, the global-script would only be shared within a single 'renderer' process (in which all page's, and global-scripts, execute in a single thread). This might not be the same in other browsers. I think you need to define how concurrent access should be handled so it can be applied to f ex a browser using a single process but a thread per top-level window. If I understand correctly it would be something like letting only one thread call inside the GlobalScript context at a time? I think it is likely impractical for windows that have javascript access to each other to be on separate threads. The relationship between the global script and pages accessing it is similar to a parent windows and an iframe that are on the same origin, or to a window and a popup window on the same origin. Objects should be able to be freely passed across both sides. For example, the global script should be able to have a JavaScript object graph which represents some application state and share it (by reference) with its clients. I don't see how it is realistic to do this when the windows are separated by a thread boundary. Therefore, I would say it is totally valid for a UA to put a bunch of windows that want to use the same global script URL in different threads, but it should group them by thread. Each thread should get its own global script that is shared among the windows that are on that thread. Btw, I thought I'd just point out that the proposal mentions this case: From the proposal text: All pages connected to the same Global Script should run on the same thread, in the same process. Since this is not always technically possible, it should be legal (and not break the applications) for there to be duplicate global script contexts within a UA. I'm glad this came up, however, since now it's more clear why such language is necessary.
Re: [whatwg] Global Script proposal.
On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilson mike...@hotmail.com wrote: Michael Nordman wrote: On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote: Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Nominally, they don't. In our design for chrome's multi-process architecture, the global-script would only be shared within a single 'renderer' process (in which all page's, and global-scripts, execute in a single thread). This might not be the same in other browsers. I think you need to define how concurrent access should be handled so it can be applied to f ex a browser using a single process but a thread per top-level window. If I understand correctly it would be something like letting only one thread call inside the GlobalScript context at a time? Process boundaries: In this past discussion there have been several mentions about having to cluster pages inside the same process if they are to share data. Why is this so, and why can't shared memory or proxied objects be an option for browsers doing process separation? A multi-process browser vendor probably *could* proxy all script calls to a truely global context across all 'renderers'... but that is not required in the proposal... and is probably even discouraged. One of the motivations for doing this is webapp performance. Proxying all script interactions across the page/context boundary works against that. Also synchronization issues get much more complicated. Implicit in the proposal is that a global-script is very inexpensive to interact with. Certainly, the ideal case is that they are in the same process. Using proxies is coming back to serialization all over again, although transparent. What I was commenting was the (seemingly widespread) notion that it is impossible to share data between process, which is not true. There is nothing stopping an implementation from using direct calls whenever process sharing is possible, and falling back to proxies in cases when processes need to be different. With this stated, I'd like to throw out a question on what do you want the most - max performance in 100% of cases, but redundant GlobalScript contexts, or max performance in most cases and singular GlobalScript contexts? I don't think any UA is realistically going to do this for v1. But sure, the door should be left open for in the future. (The initial proposal allows for both, btw.) Also, what about shared memory (I'm assuming everybody knows what this is) - apart from being non-trivial stuff, are there any specific drawbacks that renders it not useful for this case? I think it being non-trivial is the only issue. When it becomes necessary for performance reasons, I'm sure people will start looking at this. J
