On Mon, Jan 11, 2010 at 3:03 AM, Kevin Curtis <[email protected]>wrote:
> 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. > > What's 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! > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
