simple modules

[Brendan Eich]

On Feb 2, 2010, at 12:12 PM, ihab.awad at gmail.com wrote:

> On Tue, Feb 2, 2010 at 7:24 PM, Brendan Eich <brendan at mozilla.com>  
> wrote:
>> On the other hand, the second class "simple modules" proposal, plus  
>> the
>> impending Context proposal, allows A and subset-A, as far as I can  
>> tell.
>
> Yes, it allows subset-A by the creation of new Contexts.
>
> The result is not a "capability language" as commonly understood; the
> language constructs by themselves are not _prima facie_ usable to
> implement ocaps. The result is rather more akin to a capability
> operating system, in which somewhat coarse-grained units of trust
> share information freely among themselves, while having limited
> authority at their boundaries.

Once again you are changing the terms in the argument -- I was  
describing by A the full language, which won't be ocap. But subset-A  
(SES) should be ocap, per goal 5.

There is no need to create new Contexts *in the SES language*. That  
would be done when bootstrapping from a full-language <script> tag, e.g.

As I suggested last time, it's conceivable that by extending the  
RFC4329 MIME types for JS/ES we could have a <script type="application/ 
SES"> and no bootstrapping would be required (you'd have to specify  
new attributes to inject capabilities, or equivalent).


> If TC39 wishes to construct such a system in lieu of a capability
> *language* in SES, the committee needs to achieve concensus on this
> issue first -- and update the wiki! -- before commissioning module
> proposals.

Sorry, you are mistaken. The consensus is to have a statically  
verifiable object capability subset. Not to make the full language use  
object capability -- and only ocap -- primitives to erect a module  
system for the full language.

/be