No subject


Thu Dec 10 21:37:41 PST 2009


// 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 :).

--0016e65aed4ac114f8047e91c2ab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Feb 1, 2010 at 9:08 PM, Brendan Eich <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:brendan at mozilla.com">brendan at mozilla.c=
om</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex;">

In either module system approach, first-class or second-class, nothing prev=
ents a module from conveying authority, which may be unwanted or even hazar=
dous. Zero-authority modules and a service registry are as far as I can tel=
l advisory, not mandatory (but I haven&#39;t seen the full proposal yet).<b=
r>
</blockquote><div><br></div><div>A service registry sounds interesting. Is =
there a proposal out there (in this group or elsewhere) dealing with how/wh=
ere authority to platform objects or object capabilities are dished out. =
=A0</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
import JSON; // is this native code?<br>
</blockquote>
<br></div>
Why does native code matter here?</blockquote><div><br></div><div>From the =
simple module examples:</div><div><div>// compiler tries each in order</div=
><div>import [&#39;JSON&#39;, &#39;<a href=3D"http://json.org/modules/json2=
.js">http://json.org/modules/json2.js</a>&#39;] as JSON;</div>
<div><br></div><div>import is importing the &#39;native module&#39; JSON if=
 it exists. Thus &#39;native modules&#39; can be imported. This native modu=
le is harmless - or pure. No access to filesystem, websockets, webcam&#39;s=
 etc. But some native modules are/could be &#39;powerful&#39;. Andi it is d=
esirable that access to these powerful modules be constrained.</div>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
How modules, contexts (global objects) and powerful platform resources/obje=
cts/capabilities interact is interesting.<br>
</blockquote>
<br></div>
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.<div cla=
ss=3D"im"><br></div></blockquote><div>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 wh=
ich access to platform resources are mediated.=A0(Or is that wrong. Hey - i=
&#39;ll wait for the strawman :).</div>
<div><br></div><div><br></div></div>

--0016e65aed4ac114f8047e91c2ab--


More information about the es-discuss mailing list