« Return to Thread: extension modules
Re: extension modules
by Alex Russell
::
Rate this Message:
-----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
> es-discuss@...
> https://mail.mozilla.org/listinfo/es-discuss
- --
Alex Russell
slightlyoff@...
alex@... 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
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
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
> es-discuss@...
> https://mail.mozilla.org/listinfo/es-discuss
- --
Alex Russell
slightlyoff@...
alex@... 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
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
« Return to Thread: extension modules
| Free embeddable forum powered by Nabble | Forum Help |
