extension modules

kevin curtis kevinc1846 at googlemail.com
Mon Jun 22 15:46:33 PDT 2009

True - native client is currently research.
Native Client - quoting the Native Client blog - "aims to give web
developers access to the full power of the client's CPU while
maintaining the browser neutrality, OS portability and safety".
Efficient access by developers to multi-core and graphics chips for
algorithm heavy code :)

So, an issue is how to make the functionality of these multi-core and
graphics chips available to ecmascript.
One way is for ecmascript 'extension modules' to use the Native Client

Alternatively, ecmascript in the tracemonkey, v8 and nitro generates
x86/ARM code. Maybe there could be a ecmascript subset which generates
fast machine code for algorithmic intensive code. ie ignores global
object and prototype and is maybe typed. A subset similar to - or even
the same as - what Douglas Crockford is proposing for secure
ecmascript here: http://wiki.ecmascript.org/doku.php?id=ses:ses

Even if 'extension modules'  in the browser aren't available in ES6 to
third party developers it could be useful for modules that need to be
implemented in c/c++ to conform to some set of standards. These
standards could be leveraged by users of ecmascript on the server and
elsewhere outside of the browser where security is not such an issue.
A new math module with a full set of math functions would be a good
example - perhaps the code could be shared across the
nitro/v8/tracemonkey engines as a proof of concept.

On Sun, Jun 14, 2009 at 2:45 PM, David-Sarah
Hopwood<david-sarah at jacaranda.org> 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.
>> 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

More information about the es-discuss mailing list