>> - a "module context" is a set of module instances
> 
> Please call this something else.

Okay.

> It is confusing for "context" to
> mean "execution context" and "module context" depending on the
> "context".  I've called this a "system of modules" or "sandbox of
> modules" in the past.

Well, a "module system" is a language construct that provides modules. I think 
"sandbox" sort of suggests more isolation than is necessarily provided. PLT 
Scheme uses the worst possible name for the concept (I won't even say what it 
is, it's so awful).

I'll think about alternatives and update the wiki.

>> Different module contexts may have different module ID resolvers, so for 
>> example it would be possible for host environments to provide a 
>> SecureESContext that didn't allow identifiers to resolve to the "filesystem" 
>> module or the "dom" module.
> 
> This verbiage implies black-listing.  It would be good to be clear
> that the object formerly known as a "module context" should be
> explicitly populated with a white-list of module instances for SES.

Okay; all I was saying was you could create any kind of restricted context you 
want, with whatever policies you want, in a security-oriented setting. But when 
there's a proposal please do inspect the verbiage.

> ...it should
> never be necessary to edit code to give a module, or a tree of
> modules, an alternate name.  That kind of coupling has wasted many
> days of my time, integrating disparate projects with tight linkage.


A mechanism for specifying modules through a level of indirection, like Allen 
was urging, should make these kinds of problems solvable.

Dave

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to