On Jun 17, 2009, at 10:28 AM, Alex Russell wrote:
-----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.
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.
Regards,
Maciej
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
