On Sun, Jan 31, 2010 at 7:57 PM, <ihab.a...@gmail.com> wrote: > Hi Dave & Sam, > > First of all, this is an extremely well-written proposal and was a > pleasure to read; thanks for putting it out there.
Thanks! > My first set of questions are not (at least, directly) about the > first- or second-class nature of the modules as you propose them, but > rather about the isolation model implicit. Within each Context, naming > a module is equivalent to reaching a shared instance of it. This > instance must be declared at the topmost scope of the importing > module, so it is in some sense forced on the entire lexical scope of > that module. This means that, to achieve isolation via lexical scopes, > we _must_ use Contexts, implying the use of async APIs. What is the > rationale for this? First, it's also possible to achieve isolation via lexical scope by using functions, closures, and objects, as Dave's example shows. Our proposal attempts to leverage the existing facilities in EcmaScript to achieve most of isolation, using modules for name management and restricting the top-level lexical environment. Second, we expect that needing to isolate untrusted code is the uncommon case for importing a module. Therefore, making the common case simple implies that just using `import' should avoid the details of isolation. When it's important to isolate some piece of code, that code will often be from another site, or otherwise created dynamically from the perspective for the loading program. Therefore, we felt that integrating isolation with the dynamic `loadModule' is the right place. Third, the reason the API for `loadModule' is async is that encouraging synchronous dynamic loading on the web is encouraging broken webapps. However, it might not be right for `loadModule' to be standardized in ES, as Dave mentioned, and offline applications would want a synchronous version. > Another, related question is how you recommend linking in things like > the standard libraries, wherein module names referring to code > (internal linking) are in the same namespace as module names referring > to powerful objects provided by the platform (external linking). So, the way I think of it, everything in our proposal is internally linked, except insofar as a Context might specify a different behavior for the name of some module. I would recommend either using a Context-style facility for preventing or limiting access to powerful objects, as you put it, or explicit wiring together of code using objects and functions. This means that in the common case, where a simple ES program doesn't deal with trust at all, the DOM and other objects are available just as easily as they are today, but it's also possible to enforce sophisticated security policies. -- sam th sa...@ccs.neu.edu _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
