[webkit-dev] GlobalScript API.
Hi WebKit-dev, I'm hoping to get your advice on Global Script proposal and how to start implementing it as an 'experimental API' since it's not standardized yet. As part of work on Workers in WebKit and Chromium, we discussed them with our web application folks (mostly gmail). We came to the idea that in addition to workers, they need a shared script context which runs on the same UI thread and directly scriptable. Our previous take (with an invisible window running all the time in the background) was not that fruitful but it indicated the way to go. We are thankful to the members of the whatwg community for the detailed threat analysis of 'permanently running invisible pages', it helped very much. Not right away but it was absorbed :-) Current proposal reflects realization that there is a less-powerful way to achieve the same benefits. I'm looking for a way to implement it as an experimental API in WebKit and Chromium. I'm thinking it can go the similar way as webkitNotifications - surrounded by ENABLE(GLOBAL_SCRIPT) and prefixed with 'webkit' to keep the difference. I'd appreciate much your advice on the whole API and on the way to bring it into WebKit. Here is a link to the whatwg thread, with the proposal and use cases: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022113.html Here is an actual API: --- Page-level API var globalScript = new webkitGlobalScript(name, url, loadHandler, errorHandler); This returns a global scope object for the named Global Script. If one does not exist yet, creates a new one. The globalScript is sharing same process and same thread as the page running the constructor and is operational right away. No synchronization is necessary. Parameters: name - string identifying the global script. Scoped to the orogin. url - the JS resource to load, if it was not yet loaded. If the Global Script is already loaded but from a different url - the error is raised. laodHandler - a function called asynchronously when the script is loaded (or if it was already loaded by another page) errorHandler - handler for loading errors, like violation of same-origin policy or network error The GlobalScript would create its own ScriptExecutionContext-derived context if it was not yet created, and start to load the script into it. Once the script is loaded, it is evaluated in the global scope of the Global Script and loadHandlers are executed. Other pages that create a Global Script with the same name in the same origin would get the same object back. The globalScript object returned from the constructor can be immediately used to set/retrieve properties and event handlers on it. API exposed to Global Script (on its global scope object) - Timers - XHR - Navigator - localStorage - Database - Workers - Thanks, Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript API.
Ian also said (and I agree with him) that experimental implementation is needed. In fact if he added it to HTML5 already I'd be very surprised. For example, the notifications were removed from HTML5 because it was not clear to the point of writing the spec that they are even needed (as Ian said also). A lot of HTML5 is there because there were Gears with real-life experience. It's hard to see if any web mechanism will prove it viability purely theoretically. So all we are trying to do is take the feedback from app developers, produce a proposal, discuss it in the community to refine it, produce implementation and see how it goes so it can be included into HTML x at some point. It might not stand the test of time and not be standardized at the end, or it might influence some other idea - who knows? Nobody is 'pushing ahead' :-) Dmitry On Mon, Aug 31, 2009 at 6:18 PM, Peter Kasting pkast...@google.com wrote: On Mon, Aug 31, 2009 at 6:09 PM, Dmitry Titov dim...@chromium.org wrote: I'm hoping to get your advice on Global Script proposal and how to start implementing it as an 'experimental API' since it's not standardized yet. That sounds a little optimistic when so far the feedback from Hixie is I haven't added the Global Script Object proposal to HTML5. ... I really don't think it is the direction we should be taking the platform in. I realize that there have been subsequent comments objecting to that viewpoint, I'm just saying that pushing boldly ahead seems... early. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript API.
On Mon, Aug 31, 2009 at 6:44 PM, Dimitri Glazkov dglaz...@google.comwrote: Having said that, I do think the global script object idea is a bad idea. I am not convinced it's awesome either. But thought the same (and still do) about HTML5 database, and yet here it is in the standard :) Ultimately, as Dmitry said, it will be developers who vote on this. What they will pick may not be pristinely designed multi-threaded APIs, but hairy, hard-to-get-right other specs that we browser developers would've preferred them not to. I'm mainly concerned with the deleterious effects on UAs such APIs can cause. Look how much pain we suffer because of sync XHR, or the nasty tendency of pages to unnecessarily share script context (e.g. between Gmail and every page opened from within it). I haven't looked into the details of the GlobalScript API enough but my worry is that it might contribute to making problems like the latter worse, or just increasing the complexity and bugginess of the codebase in general... PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript API.
On Aug 31, 2009, at 6:09 PM, Dmitry Titov wrote: Hi WebKit-dev, I'm hoping to get your advice on Global Script proposal and how to start implementing it as an 'experimental API' since it's not standardized yet. As part of work on Workers in WebKit and Chromium, we discussed them with our web application folks (mostly gmail). We came to the idea that in addition to workers, they need a shared script context which runs on the same UI thread and directly scriptable. Our previous take (with an invisible window running all the time in the background) was not that fruitful but it indicated the way to go. We are thankful to the members of the whatwg community for the detailed threat analysis of 'permanently running invisible pages', it helped very much. Not right away but it was absorbed :-) Current proposal reflects realization that there is a less-powerful way to achieve the same benefits. I'm looking for a way to implement it as an experimental API in WebKit and Chromium. I'm thinking it can go the similar way as webkitNotifications - surrounded by ENABLE(GLOBAL_SCRIPT) and prefixed with 'webkit' to keep the difference. Here's what I think we should take a look at: 1) Does this proposal have a potential standards-track future? Relevant specific issues would be interest from other browser vendors and standards folks, interest from content producers, and our own degree of confidence that this is the right approach. Note: in some cases a prototype can be the best way to address concerns, however. In some cases we're willing to add proprietary extensions that have little hope of ever becoming a standard, but almost always we do this for the sake of non-browser use. 2) Do we have some agreement in the WebKit community that this is a good approach? It would be good for us to do some of our own design review, if this isn't going to be a standard in the foreseeable future. If we are optimistic about the future, then an ENABLE macro and a WebKit prefix would be a good way to handle things. I will do some detailed design review soon. Regards, Maciej I'd appreciate much your advice on the whole API and on the way to bring it into WebKit. Here is a link to the whatwg thread, with the proposal and use cases: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022113.html Here is an actual API: --- Page-level API var globalScript = new webkitGlobalScript(name, url, loadHandler, errorHandler); This returns a global scope object for the named Global Script. If one does not exist yet, creates a new one. The globalScript is sharing same process and same thread as the page running the constructor and is operational right away. No synchronization is necessary. Parameters: name - string identifying the global script. Scoped to the orogin. url - the JS resource to load, if it was not yet loaded. If the Global Script is already loaded but from a different url - the error is raised. laodHandler - a function called asynchronously when the script is loaded (or if it was already loaded by another page) errorHandler - handler for loading errors, like violation of same- origin policy or network error The GlobalScript would create its own ScriptExecutionContext-derived context if it was not yet created, and start to load the script into it. Once the script is loaded, it is evaluated in the global scope of the Global Script and loadHandlers are executed. Other pages that create a Global Script with the same name in the same origin would get the same object back. The globalScript object returned from the constructor can be immediately used to set/retrieve properties and event handlers on it. API exposed to Global Script (on its global scope object) - Timers - XHR - Navigator - localStorage - Database - Workers - Thanks, Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
