On Mon, Feb 1, 2010 at 9:08 PM, Brendan Eich <[email protected]> wrote:
In either module system approach, first-class or second-class, nothing > prevents a module from conveying authority, which may be unwanted or even > hazardous. Zero-authority modules and a service registry are as far as I can > tell advisory, not mandatory (but I haven't seen the full proposal yet). > A service registry sounds interesting. Is there a proposal out there (in this group or elsewhere) dealing with how/where authority to platform objects or object capabilities are dished out. > import JSON; // is this native code? >> > > Why does native code matter here? >From the simple module examples: // compiler tries each in order import ['JSON', 'http://json.org/modules/json2.js'] as JSON; import is importing the 'native module' JSON if it exists. Thus 'native modules' can be imported. This native module is harmless - or pure. No access to filesystem, websockets, webcam's etc. But some native modules are/could be 'powerful'. Andi it is desirable that access to these powerful modules be constrained. > > How modules, contexts (global objects) and powerful platform >> resources/objects/capabilities interact is interesting. >> > > Yes, the Context separation Kris presented last week, which Dave advocated > here on the list, is a good one. We need a strawman proposal on it. > > Sounds good. A Context is configured with the objects (eg dom, xhr) that the developer wants to make accessible in the Context. These objects are bound to an outer lexical frame which all modules imported into the Context can access. Contexts are the means by which access to platform resources are mediated. (Or is that wrong. Hey - i'll wait for the strawman :).
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
