-----BEGIN PGP SIGNED MESSAGE-----
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.
Regards
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
- --
Alex Russell
[email protected]
[email protected] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
iD8DBQFKOSfUz3jiQlnDlyMRAiWMAJ90Eq8rnB+CTd21nMjoijT6WhLz4ACbBy8b
53n8s/hnUZmSVKP0Mo8Uh5s=
=Ksrr
-----END PGP SIGNATURE-----
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
