You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

XPConnect (Scriptable Components)

Overview

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.

Non-Goals

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.

Architecture

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.

Status (4 June 1999)

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.

Resources:

Flames/suggestions
Michael Ang <mang@subcarrier.org>
Author
John Bandhauer <jband@netscape.com>
Last modified
1 Feb 2000