Roadmap for language agnostic scripting support
Replacing the DOM Binding with XPIDL Interfaces
Component Definition Language
<code>nsIXPCSecurityManager</code> to have a policy that allows calls across selected DOM/XPConnect interfaces and not others.
Once the DOM interfaces have been recast using XPIDL, an alternative scripting environment could, in theory, be supported in the browser by simply writing an XPConnect binding for the language (e.g., "PerlConnect" or "PythonConnect"). The reality of the situation is that there are many places in the code where a JS binding has been assumed, and these would need to be ferreted out. It's likely that several design decisions would need to be revisited, and additional indirection or abstraction would need to be added.
- There are many reasons that XPConnect is preferable over the generated C++ DOM binding:
- XPIDL is far more expressive than the simple IDL used to define the DOM interfaces. (But currently not expressive enough to handle some of the DOM bindings: this is a problem that needs to be dealt with.)
- The type libraries that specify the runtime binding are a decimal order of magnitude more compact than generated C++ code.
- XPConnect potentially allows for mediation between two (or more) different scripting environments.
- In fact, for a finite set of component types, we could hard code this in some simpler scheme.