[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