extension modules

Maciej Stachowiak mjs at apple.com
Tue Jun 23 11:27:45 PDT 2009

On Jun 17, 2009, at 10:28 AM, Alex Russell wrote:

> 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.

For what it's worth, we probably wouldn't use a standardized interface  
to hook up DOM objects to the JS VM in WebKit, even if we provided it  
for third-party clients. We have a few public interfaces for this  
(such as NPRuntime) but for objects implemented by the browser, we  
want the freedom to change the interface at any time, in case we come  
up with a higher-performance way of doing it. Our internal interfaces  
also make use of inlining in a way that would not be appropriate for a  
public API.

I don't know if this significantly affects the value of your idea or  
if you were even proposing this sort of thing.


More information about the es-discuss mailing list