brendan at mozilla.com
Tue Feb 2 12:45:49 PST 2010
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>
>> On the other hand, the second class "simple modules" proposal, plus
>> impending Context proposal, allows A and subset-A, as far as I can
> 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
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.
More information about the es-discuss