<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:'times new roman', 'new york', times, serif;font-size:12pt"><div>I thought I would also mention that contexts (as in execution context), sandbox,&nbsp;</div><div>security and other terms&nbsp;are also heavily used in <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html">html5</a>. Defining a module framework&nbsp;</div><div>without at least being familiar with current and upcoming browser environments&nbsp;</div><div>may result in an implementation that is at odds with html5 entities which use&nbsp;</div><div>similar terminology. For example,&nbsp;a SecureESContext would probably prevent&nbsp;</div><div><a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages">cross-document messaging</a>,&nbsp;<a
 href="http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#channel-messaging">channel messaging</a>&nbsp;and other mechanisms that exist or&nbsp;</div><div>are being defined in html5.&nbsp;Strictly speaking cross-document messaging violates&nbsp;</div><div>TCB since&nbsp;existence&nbsp;of adjacent iframes and their source domains can be determined. &nbsp;</div><div>Yes I'm not sure current module strawmen define a general mechanism where&nbsp;</div><div>module-to-module&nbsp;communication can occur.</div><div><br></div><div>Perhaps to&nbsp;complement the discussion,&nbsp;there is a variety of literature which describes modules&nbsp;</div><div>in different ways. Given one goal of harmony is to make programming in the large&nbsp;</div><div>easier, I would think a module framework's first goal is to make it easier to organize code.</div><div><br></div><div>Some papers on modules with a few choice
 quotes.</div><div><br></div><div>Functions, Frames and Interactions. Claus Reinke.</div><div><i>&nbsp;&nbsp;'A module is a ... collection ... of elements. It provides a separate namespace with explicit control of import/export.'</i></div><div><br></div><div>Modular Object-Oriented Programming with Units and Mixins. Findler, Flatt</div><div><i>&nbsp;&nbsp;'A module delineates boundaries for separate development...'</i></div><div><i><br></i></div><div><i><span class="Apple-style-span" style="font-style: normal; ">Metalevel Building Blocks for Modular Systems. Jagannathan</span></i></div><div><i>&nbsp;&nbsp;'allow ... module elaboration with minimal program rewriting...'</i></div><div><i><br></i></div><div>The Influence of Software Module Systems on Modular Verification. Li, Fisler, Krishnamurthi.</div><div><i>&nbsp;&nbsp;'feature-oriented modules ... simplify key software engineering problems such as configurability, maintainability, and
 evolution.'</i></div><div><i><br></i></div><div><i><br></i></div><div><i>kam</i></div><div><br></div><div><br></div><div><br></div><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><br><div style="font-family:arial, helvetica, sans-serif;font-size:13px"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Kris Kowal &lt;kris.kowal@cixar.com&gt;<br><b><span style="font-weight: bold;">To:</span></b> David Herman &lt;dherman@mozilla.com&gt;<br><b><span style="font-weight: bold;">Cc:</span></b> es-discuss Steen &lt;es-discuss@mozilla.org&gt;<br><b><span style="font-weight: bold;">Sent:</span></b> Tue, February 2, 2010 6:23:55 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: simple modules<br></font><br>
On Tue, Feb 2, 2010 at 5:27 PM, David Herman &lt;<a ymailto="mailto:dherman@mozilla.com" href="mailto:dherman@mozilla.com">dherman@mozilla.com</a>&gt; wrote:<br>&gt; On Feb 2, 2010, at 5:03 PM, Kris Kowal wrote:<br>&gt;&gt; Presuming that in the proverbial glossary a "Context" is what ES<br>&gt;&gt; presently calls an execution context that has some intrinsic<br>&gt;&gt; "Primordials", and a "Sandbox" is a mapping from unique module<br>&gt;&gt; identifiers to modules (albeit instances or makers depending on what<br>&gt;&gt; proposal you're talking about), does this proposal suggest that there<br>&gt;&gt; is exactly one "Context" for every "Sandbox" and that any "module<br>&gt;&gt; block statement" evaluated in a context populates the corresponding<br>&gt;&gt; sandbox with a mapping from the given module identifier to the first<br>&gt;&gt; class exports object of that module?<br><br>&gt; Not quite sure how to unpack the question. Let me try a quick
 sketch, at least for the simple modules system:<br>&gt;<br>&gt; - a "module ID resolver" is a mapping from module ID's to module instances<br>&gt; - a "module context" is a set of module instances<br><br>Please call this something else.&nbsp; It is confusing for "context" to<br>mean "execution context" and "module context" depending on the<br>"context".&nbsp; I've called this a "system of modules" or "sandbox of<br>modules" in the past.<br><br>&gt; 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.<br><br>This verbiage implies black-listing.&nbsp; It would be good to be clear<br>that the object formerly known as a "module context" should be<br>explicitly populated with a white-list of module instances for SES.<br><br>&gt; There would be an API for dynamically
 evaluating code in a given context; roughly a `loadModule' that takes a Context argument (or is a method of Context).<br><br>Tell me more about this "loadModule" and how it works.&nbsp; I am concerned<br>that modules would be "autonomous"; I firmly believe that a chunk of<br>code should never select its own name, or more to the point, it should<br>never be necessary to edit code to give a module, or a tree of<br>modules, an alternate name.&nbsp; That kind of coupling has wasted many<br>days of my time, integrating disparate projects with tight linkage.<br><br>Kris Kowal<br><br>P.S., for some liesure reading, here is the Narwhal CommonJS "module<br>context" implementation:<br><span><a target="_blank" href="http://github.com/280north/narwhal/blob/master/lib/sandbox.js">http://github.com/280north/narwhal/blob/master/lib/sandbox.js</a></span><br><span><a target="_blank"
 href="http://github.com/280north/narwhal/blob/master/lib/loader.js">http://github.com/280north/narwhal/blob/master/lib/loader.js</a></span><br>_______________________________________________<br>es-discuss mailing list<br><a ymailto="mailto:es-discuss@mozilla.org" href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br></div></div><div style="position:fixed"></div>


<!-- cg5.c4.mail.gq1.yahoo.com compressed/chunked Wed Feb  3 01:43:57 PST 2010 -->
</div></body></html>