XPConnect is a technology which enables simple interoperation between XPCOM and JavaScript.
XPConnect allows JavaScript objects to transparently access and manipulate XPCOM objects. It also enables JavaScript objects to present XPCOM compliant interfaces to be called by XPCOM objects. A main goal is that objects communicating from either side of an XPCOM style interface should not generally need to know or care about the implementation language of the object on the other side of the interface.
XPConnect's primary reason for existence is to replace handwritten code used in places where native code needs to interact with JavaScript code. Examples are the Document Object Model (DOM) and the Smart Update module. An interim solution to this problem is currently in use in mozilla. That solution uses an idl compiler (idlc) to generate a great deal of C source code to reflect objects into the JavaScript runtime using the JSAPI. That source is then compiled into the mozilla binaries. XPConnect provides a more dynamic solution with a much smaller code footprint.
XPConnect also enables interaction of XPCOM and JavaScript objects in new places. The XPFE will require JavaScript interaction with a large collection of native widgets which go far beyond the 'traditional' set of DOM widgets. As the number and versatility of XPCOM objects grows we envision an evolving toolkit of objects being available to build JavaScript applications (both inside and outside of browsers). We also imagine building custom widgets implemented using JavaScript which can be used just as the native XPCOM widgets are used.
XPConnect (at least in its initial incarnation) does not directly
support scripting of MS COM objects. IDispatch interfaces are not
supported. It does not support scripting of XPCOM objects whose interfaces have
not been declared in XPIDL. It does not support scripting of XPCOM objects that
break the XPCOM conventions; e.g. non-standard return types, use of C++ default
parameters, assumptions about the underlying C++ type of the object implementing
a given interface, etc.
XPConnect makes no attempt to support mapping to languages other than JavaScript. The XPIDL compiler generates C++ specific headers and binary typelibs needed for mapping to JavaScript. Someone could extend the compiler to generate additional formats and/or write glue code to use existing typelibs to map to other languages. But this is not a goal of XPConnect.
In order to work with XPConnect an XPCOM interface must be declared using
XPIDL.
This is a Corba IDL based language with some extensions to support added XPCOM
and XPConnect requirements. The XPIDL compiler is used to generate both C++
header files and XPConnect
typelib files.
The C++ header files are functionally identical to the header files currently
being written by hand for all XPCOM interfaces. The typelib files allow the
XPConnect
glue code
to dynamically build proxy objects at runtime to dispatch method calls and
handle property accesses between XPCOM and JavaScript objects. For most XPCOM
interfaces this will be entirely transparent. The system also supports an
nsIXPCScriptable interface that will allow XPCOM objects with
scripting specific requirements to have more control over how they are
represented as JavaScript objects.
XPConnect is now part of the builds on all platforms. Ports of xptcall are needed for some platforms to keep those platforms running Mozilla. RDF and mail/news are defined in XPIDL, and some of the AppCores modules are coming along as well. We are working on improved docs and pushing and prodding everyone to write their new and existing interfaces in xpidl.