Roadmap for language agnostic scripting support

	THIS PAGE MAY BE OUTDATED
	This article is in parts, or in its entirety, outdated. Hence, the information presented on this page may be incorrect, and should be treated with due caution until this flag has been lifted. Help by editing the article, or discuss its contents on the talk page.

A long term goal for Mozilla is to support multiple scripting environments in addition to JavaScript; for example, Perl and Python. This will allow developers to use the language of their choice to manipulate and implement components. Furthermore, a component will be able to manipulate (or be manipulated by) another component without regard for the language in which either is implemented.

The current XPConnect implementation allows for this sort of seamless integration between JavaScript and natively-implemented components. Specifically, it allows a JavaScript both manipulate and implement arbitrary XPCOM. interfaces that have been defined using XPIDL, a CORBA-like interface description language.

Currently, there are many important interfaces that are accessible from JavaScript that are not defined using XPIDL. Most notably, the W3C DOM is accessible from JavaScript, but using a completely different binding mechanism.

The purpose of this document is to lay out an incremental plan to remove the DOM-specific JavaScript binding, replacing it with interfaces declared using XPIDL. This lays the necessary groundwork for implementing a second, non-JavaScript, version of XPConnect (ostensibly, Perl or Python) that has full access to Mozilla's componentry and W3C DOM implementation.

Plan

Replacing the DOM Binding with XPIDL Interfaces

As noted above, we currently have two mechanisms for binding a script environment into Mozilla. The DOM binding uses generated C++ code to provide JavaScript-specific linkage, and was written to deal with the vagaries of the Level-0 JavaScript DOM. XPConnect uses a platform-independent type library with platform-specific method dispatch code to dynamically determine runtime binding. (footnote 1)

The big first step towards supporting another scripting environment is to unify the current mechanisms used to integrate with JavaScript. This will involve a fair amount of work.

Component Definition Language

An XPConnect interface flattening scheme is required for reflecting multiple DOM interfaces on JavaScript objects for cases where the interfaces are not part of an inheritance chain. This work is not done, but is not huge. XPConnect already handles reflecting methods from inherited interfaces. Presumably, we need a Component Definition Language to give XPConnect the "interface set per component" information in order to do the flattening. (footnote 2)

Security

Right now we have a binary model in XPConnect: JavaScript in content (presumably) can't cross XPConnect boundaries. We would need to actually use the power of the nsIXPCSecurityManager to have a policy that allows calls across selected DOM/XPConnect interfaces and not others.

Implementing a non-JavaScript Version of XPConnect

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.

Notes

1. 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.
   • The generated C++ DOM binding is extremely JavaScript-specific, and it is extremely unlikely that any of it would be re-usable for another scripting language.
2. In fact, for a finite set of component types, we could hard code this in some simpler scheme.