[webkit-dev] GlobalScript API.

Leo Meyerovich lmeyerov at eecs.berkeley.edu
Tue Sep 1 21:16:15 PDT 2009

Perhaps worth reexamining lessons learned from (PLT?) Scheme's 
distinction between units and modules.

Security, assuming & beyond the SOP, is worth considering. Module 
loading would be a giant boon for writing secure apps if the loader can 
specify the load environment (e.g., empty it, share the DOM / 
prototypes, or stipulate fresh / isolated ones). It's unclear what 
guarantees the loadee would want (e.g., frame-busting)... perhaps a 
discussion that could be more informed by the OCaps list that is active 
in the basic topic.

- Leo

Patrick Mueller wrote:
> 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.

More information about the webkit-dev mailing list