extension modules

Alex Russell alex at dojotoolkit.org
Wed Jun 17 10:28:51 PDT 2009

Hash: SHA1

On Jun 14, 2009, at 6:45 AM, David-Sarah Hopwood wrote:

> kevin curtis wrote:
>> Python has a concept 'extension modules' where module can be
>> implemented in c/c++. Also the idea of running native code in the
>> browser has been put forward by Google's native client for running  
>> x86
>> in the client. MS - i think - are researching something similar.
> The idea of running native code securely in the browser is speculative
> and unproven. Nothing should be standardized in this area unless and
> until such approaches can be demonstrated to have a reasonable chance
> of resisting attack. To do so would be to repeat previous mistakes  
> that
> have led to the insecure web we currently have.

Right, but that doesn't mean folks authoring C/C++ extensions might  
not be able to work w/ a single IDL and set of object lifecycle  
guarantees. Every browser in the planet does something similar here in  
order to hook up C/C++ DOM objects with the JS VM, and witnessing how  
V8 and JSC have had to approach this, it seems natural that JS (say,  
on the server) would be well served by some sort of unified-ish way of  
saying "here's how my C++ class can be hooked into a JS object  
lifecycle". The NPAPI example shows that it can be done at runtime,  
and the stuff in good interpreters today (getters, setters, etc.) are  
sufficient to facade enough of the API surface area to make these  
things happen. What's missing is something that's slightly more  
efficient than NPAPI, which both implies a browser runtime, a separate  
process (for reliability), and a chatty protocol that thunks through  
twice for every method call.


>> c/c++ isn't going anywhere and the relationship between ecmascript  
>> and
>> c/c++ is interesting. Are there any proposals for something like
>> 'extension modules' for ES6 or do the variations in the engine
>> implementations preclude such a thing?
> As far as a foreign function interface for non-web uses of JavaScript
> is concerned, that is something that might in principle be worth
> standardizing (probably separately from ES6).
> However, the internal C/C++ interfaces typically used by current JS
> implementations are highly error-prone, make too many assumptions  
> about
> implementation details (particularly memory management), and are not
> suitable for wider use.
> -- 
> David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

- --
Alex Russell
slightlyoff at google.com
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

Version: GnuPG v1.4.2 (Darwin)


More information about the es-discuss mailing list