638
edits
Roadmap for language agnostic scripting support: Difference between revisions
Roadmap for language agnostic scripting support (view source)
Revision as of 16:43, 14 September 2007
, 14 September 2007fix plus signs in migrated content
No edit summary |
m (fix plus signs in migrated content) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 13: | Line 13: | ||
=== Replacing the DOM Binding with XPIDL Interfaces === | === 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) | 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. | 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. | ||
| Line 32: | Line 32: | ||
== Notes == | == Notes == | ||
# There are many reasons that XPConnect is preferable over the generated C DOM binding: | # 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.) | #* 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. | #* 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. | #* 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. | #* 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. | ||
# In fact, for a finite set of component types, we could hard code this in some simpler scheme. | # In fact, for a finite set of component types, we could hard code this in some simpler scheme. | ||