White Paper: Components in the GNOME Project

The Uses of CORBA

CORBA is used in the GNOME system in a number of places:

Exporting an Application's API
CORBA is used in GNOME to export the internal engine of an application to the rest of the system. Any CORBA client (GNOME compliant applications, regular Unix applications, remote clients running on a different operating system) can use the services that these application provides.

Currently, gmc, guppi, and gnumeric support this feature and many other applications are following this tendency. For example, a CORBA aware application can manipulate a spreadsheet in gnumeric. All of the Gnumeric spreadsheet's features are accessible trough the CORBA interfaces defined on the GNOME::Gnumeric module.

The exporting of the interface is essential in building a true component system.

In addition to exporting the API, GNOME is generating a list of standard interfaces that other applications can be written to. For example, the interface Desktop::Editor defines an interface to an editor. This means that an application (such as a Mail client or an IDE program) that is developed using these interfaces can decouple itself from a specific implemenation of the interface.

The user can select its favorite implementation of the Desktop::Editor interface, and this tool will integrate with the rest of the system.

General IPC and RPC Mechanism
Another common task among developers is to have separate processes communicate at some level: either to split functionality, or to separate the processing of some task, or to maximize paralelization. CORBA provides a standard, and easy to use Remote Procedure Call (RPC) system that allows different applications to communicate with each other.

Oftentimes in the UNIX world, little IPC/RPC protocols are hand-crafted individually to communicate between two or more applications. These implementations have strong drawbacks: These protocols have to be debugged every time that they are implemented; They are difficult to maintain: as time passes, people tend to extend these protocols to address new functionality. These protocols tend to get bloated and they become diffiult to maintain, to document and to standarize. We do say that these hand-crafted protocols do not scale.

Keeping code simple and maintainable is one of the major goals of the GNOME project: the code we are writing needs to be ready to be modified, enhanced and extended for a long period of time. It is more important to provide an easy to maintain framework to us than anything else.

Additionally, if another developer needs to use these hand-crafted protocols, their only option is to figure out what the protocol is by reading the source code or hoping that the protocol is documented (and many times they are not).

GNOME has tried to minimize these issues by using CORBA as its communication mechanism. CORBA was designed to tackle these problems on a larger scale, making it more than powerful enough to handle GNOME's needs. Once an application designer has learned how to use CORBA in GNOME, they can use it everywhere. In addition, GNOME will handle the actual activation of the call, so the application does not need to worry about it.

Currently, both the GNOME Control Center and the GNOME Panel use CORBA heavily to communicate with their embedded applications. Additionally, a few games use CORBA as a communication protocol for networked play. Other examples of CORBA (and more specifically ORBit) used in this fashion, are the Mod_CORBA Apache module and the Dents DNS server..

Mod_CORBA is a package that exports much of APACHE's module API via an interface. With this package, you can talk to apache in any CORBA supporting language. It will work without recompiling, or even restarting APACHE. Dents will allow you to access a DNS server via CORBA. It will facilitate such things as remote administration and control of the server. Both of these packages are different from other config tools, as they modify a "live" application. This means that changes happen to the current server on the fly, rather then just modifying one of its config files and restarting it.

Scripting
It is a very important goal of the GNOME project to provide scripting support throughout the system. This support will allow an application developer and advanced users to automate common tasks and rapidly control GNOME features. This is similar to the role that macros and Visual Basic play in the Windows world. The user can write a script to manipulate a gnumeric spreadsheet, perform customized spell checking, or automate some repetitive tasks (this only requires your scripting language to support CORBA).

All of the major scripting languages available on UNIX (such as Perl, Python and Java) have CORBA bindings so they can control components remotely. Additionally, GNOME and GTK+ were written with scripting in mind, and as a result, have a large number of language bindings. See the GTK+ homepage for a complete listing.

Defining system services
Many of the procedures carried on most Unix systems these days do not have a standard interface and they rely entirely on tradition. Many times programmers write scripts with various degrees of robustness that manipulate system-configuration settings. The less experience the programmer has, the more likely his scripts that manipulate system information will be prone to sublte errors, race conditions, broken file updates, non-atomic operations and so on. For example, consider the task of programatically adding users, internet services, querying the mail queue, querying the printer queue and so on.

We want to define standard interfaces for various system-related tasks as part of the GNU project. CORBA-based servers would encapsulate all of the details for administering a system and taking the necessary steps to carry their job correctly. Instead of relying on a script to add users, the application writer would invoke various methods on the the System::admin::user interface. To queue messages, instead of relying on a specific mail transfer agent program with some specific semantics to be installed in some magical location, the user would just invoke the System::Mail::deliver interface. The same applies to querying the input mail (by using the GNOME::Mailer interfaces), and the same applies to querying any of the system services (instead of depending on system-specific hacks).

Bonobo
Bonobo is the GNOME Document model. It lets document-based applications embed themselves in each other. Its design is influenced heavily on OLE2 and Active X by Microsoft and has a similar functionality. It is currently in Alpha state, and should be used only by developers, but has been used successfully to embed a Guppi graph within Gnumeric.

For those unfamiliar with OLE2, it provides a framework for applications to embed themselves within the same GUI framework. This facilitates, for example, a graph to be embedded in a word-processing document, or a spell checker to be embedded in a plotting program. Bonobo also provides the ability to wrap GTK-style objects around a component, allowing an application developer to use one in his application. A more technical description is available in the BONOBO cvs repository.