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 functionality. 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<[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
