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