Module isolation

Kevin Curtis kevinc1846 at googlemail.com
Mon Jan 11 03:03:18 PST 2010


Re isolation, sandboxing - and modules.

Is there is a case for the ability to 'configure and freeze' a global object
for sandboxing, SES and maybe modules. Indeed the 'restricted eval' can be
seen as more specific case of an eval which takes a 'configured and frozen
global' environment. With a frozen global all bindings should be able to be
resolved at the time eval is called. Effectively, restricted evaled code
will have 'const x = <object>' binding added to it's scope - where 'x' is a
property from the configured global object.

N.B - if a restricted eval takes a second param as a string to configure the
'global environment' for the evaled code then it would avoid the closure
peeking issue.

A key question is how a module system (and the ECMAScript engine generally)
parcels out access to platform objects or capabilities (like
XMLHttpRequest). Explicity via parameter passing  or implicitly via a more
'dependency injection container' style using a configured (and frozen)
'global' object. With the latter approach the developer could configure a
'global' object which hides the DOM with a jquery-ish module - and all
modules imported (including modules importing module) could use the jquery
module without explicity importing it.

First-class native modules would be great:
typeof mymod -> "Module".
Though as has noted elsewhere  - we need this functionality SRTL - it's
crucial!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100111/0748273c/attachment.html>


More information about the es-discuss mailing list