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 <pkasting@google.com> wrote:

On Mon, Aug 31, 2009 at 6:09 PM, Dmitry Titov <dimich@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

On Sep 1, 2009, at 4:13 PM, Dmitry Titov wrote:

Thanks a lot Maciej!

As a note to the API described in this thread: there was a proposal in private thread to replace the JS constructor with 4 parameters with a tag:

instead of var globalScript = new webkitGlobalScript(name, url, loadHandler, errorHandler);

to have this: <webkit-globalscript name='...', src='url', onload=... onerror=...></ webkit-globalscript>

The first tag with a specific name that provides a src or inline script or injected with innerText would effectively supply 'initial script'. The later-encountered tags withthe same name would have their initial script ignored and simply connected to the same one. The tag's DOM element would be EventTarget (for load and error) and have a 'context' property to pull the global scope object of the script.

Why is a tag better for this than a constructor or function? Regards, Maciej

Dmitry

On Mon, Aug 31, 2009 at 7:18 PM, Maciej Stachowiak <mjs@apple.com> wrote:

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

Dmitry Titov wrote:

Thanks a lot Maciej! As a note to the API described in this thread: there was a proposal in private thread to replace the JS constructor with 4 parameters with a tag:

instead of var globalScript = new webkitGlobalScript(name, url, loadHandler, errorHandler);

to have this: <webkit-globalscript name='...', src='url', onload=... onerror=...></webkit-globalscript>

My initial reaction is ... urghhh ...

The first tag with a specific name that provides a src or inline script or injected with innerText would effectively supply 'initial script'. The later-encountered tags withthe same name would have their initial script ignored and simply connected to the same one. The tag's DOM element would be EventTarget (for load and error) and have a 'context' property to pull the global scope object of the script.

The element is much less flexible than JavaScript APIs. For instance, I can imagine I may want to conditionally use a global script. If we only had the element, I'd have to construct one in JS, then inject it into the DOM. Calling a constructor would be a lot less work. :-) -- Patrick Mueller - http://muellerware.org

On Tue, Sep 1, 2009 at 9:07 PM, Oliver Hunt <oliver@apple.com> wrote:

On Sep 1, 2009, at 4:13 PM, Dmitry Titov wrote:

Thanks a lot Maciej! As a note to the API described in this thread: there was a proposal in private thread to replace the JS constructor with 4 parameters with a tag:

instead of var globalScript = new webkitGlobalScript(name, url, loadHandler, errorHandler);

I know this as been discussed a million times already, but this bugs me. What if you want to load multiple scripts or populate a globalscript from the parent page(s)? I prefer the other importScript-like ideas.

I'd much prefer if we made creating a globalScript synchronous and with no network request. The async load of iframes with an empty src is really frustrating to web developers and causes lots of bugs and performance problems in practice. If we keep this syntax, we should at least try and special-case leaving out the url argument so that we load the globalscript synchronously. I'm not sure if this is really feasible given the time it takes to create a Document, but we should at least try it and measure the performance..

to have this: <webkit-globalscript name='...', src='url', onload=... onerror=...></webkit-globalscript>

This actually displays one of the issues i have with global script as a concept, you are basically just doing<iframe src="..."></..>

And that gives you a context that achieves almost everything the global script concept gives you.

People keep saying that this is no better than a new window or an iframe because you can script those synchronously across pages, but that totally misses the point. The the frame/script/window survives when it's parent page is closed if there's another page pointing to it and, in some versions of this proposal, it survives same-origin page navigations. That isn't true of iframes or windows and is exactly what makes these useful. For the record, I'm on the fence about this idea, but it seems worth experimenting with if there are web pages that will follow through with using them, understanding that they're experimental APIs of course. Ojan

This actually displays one of the issues i have with global script as a

...

concept, you are basically just doing<iframe src="..."></..>

And that gives you a context that achieves almost everything the global script concept gives you.

People keep saying that this is no better than a new window or an iframe because you can script those synchronously across pages, but that totally misses the point. The the frame/script/window survives when it's parent page is closed if there's another page pointing to it and, in some versions of this proposal, it survives same-origin page navigations. That isn't true of iframes or windows and is exactly what makes these useful.

This is exactly right, the most interesting aspect is its lifetime that makes it a nice place to call 'the application'. It can keep the app state while pages navigate between each other, making browser history and page cache just work. And it can make windows independent of each other without loading the whole app in each of them... There was an interesting presentation<http://en.oreilly.com/velocity2009/public/schedule/detail/7611>from Facebook folks at O'Reilly Velocity conference (pdf slides here <http://figushki.com/test/FacebookFrontEnd_Velocity2009.pdf>) where they describe 'quicklings' - the elaborate way to avoid full page loads. Also they try to cache as much as possible in the 'live' form in memory - so they can keep those fast caches up to date. This is similar to what many applications are doing today - trying to keep a single 'main' page alive and inventing their incarnations of navigation and history. Global Script could be useful there as a replacement for those ad-hoc mechanisms. Dmitry

Patrick Mueller wrote:

Dmitry Titov wrote:

...

Here is an actual API: --------------------------- Page-level API

var globalScript = new webkitGlobalScript(name, url, loadHandler, errorHandler);

I've mentioned before that this API turns out to be very similiar to the serverJS notion of a "module".

https://wiki.mozilla.org/ServerJS/Modules/SecurableModules

Differences are the name: require -> webkitGlobalScript; semantics about sharing across pages (not relevant to the serverJS work); the "exports" variable in the module which provides the reference to the globalScript return value the client sees; and that this is async vs. serverJS's sync model.

Of most interest is the notion of the "exports" variable. Instead of exposing the "global" scope of the global script itself as the return value, you actually have to assign something to the exports variable from within the global script for it to be available in the caller. The nice thing about this is that it provides a nice way to create private references within your global script.

Another interesting aspect of this is that it easily allows a global script author to use some library without that library infecting the pages' (clients of the global scope) scopes. For instance, one global script could pull in jQuery, another could pull in Prototype, or a different version of jQuery. Since only properties specfically added to "exports" are available to pages' scopes, there's no negative interaction between jQuery and Prototype. They live in the "globals" of each global script, which aren't visible to anyone else. Of course, monkey patching is still a problem - or is it? Does each page scope and global scope get it's own set of globals? eg, only one Object object? I was thinking originally that you'd want to share built in globals like Object and Array, but now I don't see how that would be possible. -- Patrick Mueller - http://muellerware.org