A lingua franca for application extension

During his keynote presentation at OSCON last year, Ubuntu founder Mark Shuttleworth described application extensibility as an important enabler of innovation and user empowerment. Citing the Firefox web browser and its rich ecosystem of add-ons as an example, Shuttleworth suggested that the Linux community could deliver a lot of extra value by making scriptable automation and plugin capabilities available pervasively across the entire desktop stack.

The concept is very compelling and has a long history. There are many examples from which to draw inspiration, because similar capabilities are present in virtually every platform. Long ago, scripting languages called Guile and Tcl were the dominant extension languages of the Linux platform. Although both still exist today, they are somewhat anachronistic and are no longer widely used.

In today's world, demand for application extensibility is rising, and there is a strong need for interoperability between extension systems. To accommodate those requirements, it's a clear that the desktop must have a lightweight lingua franca for scripting and extension. To gain traction on the desktop, the language has to be widely known, easy-to-use, and naturally conducive to rapid development. JavaScript, which meets all of these requirements, is becoming a compelling contender for the role. The ubiquity of web development expertise guarantees broad JavaScript familiarity, and the growing trend of convergence between the desktop and the web also contribute to JavaScript's suitability as a desktop extension solution.

The developers of the open-source Qt toolkit, the underlying framework of the KDE desktop environment, figured this out a few years ago and introduced a native scripting engine based on JavaScript's syntax (it's a standards-compliant implementation of ECMA-262) directly in the toolkit. It leverages Qt's object system to provide dynamic access to native Qt widgets, with full support for Qt's signal and slot system.

We recently took a close look at how these scripting capabilities are used in Amarok, KDE's popular open source audio player. A significant amount of Amarok's functionality was implemented with scripting and, as I demonstrated in the article, it's trivially easy for end users to add a wide range of additional features.

The GNOME platform could soon have similar support for scripting. Two projects have emerged that aim to bring rich JavaScript bindings and embedded scripting functionality to GTK+ application developers. The Seed project is based on WebKit's JavaScriptCore engine and the Gjs project leverages Mozilla's SpiderMonkey engine.

GObject introspection



Both projects take advantage of a new and highly experimental introspection feature that is being integrated into GObject, the type system and object model framework that is used in GTK+ and other libraries within the GNOME ecosystem. The GObject introspection system supplies programmatically-accessible type metadata for GObject-based libraries.

Static analysis tools automatically generate the metadata by analyzing header files and extracting annotations from source code. The metadata is then stored in XML-based GObject Introspection Repository (GIR) files. One of the numerous advantages of having this type metadata available is that it dramatically reduces the complexity inherent in supplying language bindings for libraries.

One of the earliest experiments that demonstrated the viability of using GObject introspection for dynamically generating language bindings was the PyBank binding framework. GObject introspection developer Johan Dahlin showed that it was possible to generate bindings at runtime as needed using the GObject metadata. Seed and Gjs use a similar approach.