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.
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
