The Component Object Model of Linux.
The next big step forward?.
The Unix philosophy has always been rather simple. Each portion of the OS or each tool was meant to do only one job and do it well. Often, you’ll find that a simple (read understandable and clear) algorithm has been preferred over an obviously superior but complicated solution. While such small tradeoffs may seem unnecessary, a fine example of the resultant advantages is the wizardry that’s possible with small programs like grep and sort and by linking these together with pipes. Another example is the distinction between an MTA (Mail Transport Agent) like procmail or fetchmail and an MUA (Mail User Agent) like pine or elm. Rather than have one single mail program that does everything, the Unix way is to have a component that deals with getting the mail while another component deals with the creation, editing, and manipulation of messages.
The greatest benefit in this approach is that you can choose what components you want to use, and if the components are programmed well, they’ll work seamlessly with each other. This translates into more choice for the user, which is what Linux is all about, isn’t it? Another example of a similar attempt is the commonly known OLE (Object Linking and Embedding) or the more current COM/DCOM (Component Object Model). These technologies strive to define the interface between components well enough for them to work with each other. The benefits of such an approach are immense, even in terms of development and programming. As the old programmer saying goes, "There’s no real need to re-invent the wheel—it’s been done before!" Rather than struggle with creating, debugging, and testing a graphics program designed to produce a pie-chart, it’s more prudent to use a software component that does that right away. A target scenario (though idealistic) would be one in which all the programming that’s done is nothing but glue code for components from standard libraries. This trend can be seen in the Standard Template Library (STL) and generic programming efforts of ISO C++ and the java.util libraries in Java.
Unfortunately, the simple abstractions of a command line and pipes rarely scale up to the requirements of an average GUI-based environment. Most GUI environments rely on meta-data, or data that describes how data is stored. Sounds complicated? In terms of a file-system, meta-data may range from what application is to be associated with a particular file extension—such as xmms with MP3—to who and how to interact with a document. This usage of meta-data not only improves the user friendliness of a system, but also increases user throughput when working on it. There’s an increasing trend towards using meta-data in GUI systems to automate many commonly performed tasks.
In today’s world, where complicated commands and arcane command line arguments are generally frowned upon, the Open Source community needed something to set interoperability between objects in Linux. Bonobo is such a standard. This was pioneered by the GNOME group (http://developer.gnome.org), which is responsible for the popular and widespread Window Manager GNOME.
To allow such components to communicate and execute each other, you require a communication mechanism as well as a control mechanism. A functional solution to this problem is RPC (Remote Procedure Call). The more recent and object-oriented solution to this problem has been CORBA—Common Object Request Broker Architecture (www.omg.org)—which is going to become more important as we proceed to more distributed computing. This standard is especially suited to Linux due to its open nature.
A fine example of the community’s efforts can be found in the CORBA implementation being used in Bonobo. Initially, a CORBA implementation known as MICO was planned. MICO is a popular implementation that’s often used to teach and explain CORBA. It is cleanly implemented, but suffers from some performance deficiencies. The community responded by creating an implementation of CORBA called ORbit (www.labs.redhat.com/orbit/), which is now reputed to be amongst the leanest and fastest CORBA implementations available. Now, with ORbit, developers can look forward to inter-process communication with a useful abstraction, a secondary benefit that is often missed in evaluating the Bonobo component model.
Amongst many implementations of Bonobo, (http://developer.gnome.org/arch/component/bonobo.html), the first Bonobo effort that springs to mind is the document embedding that was popularized by Microsoft’s OLE. The Baboon model of Bonobo allows users to embed documents within other documents, retaining the ability to edit, modify, and change the original embedded document. For example, you can embed a chart in a text document, which when entered would allow the underlying spreadsheet application that created the chart to execute. You could then modify, edit, and change the spreadsheet data and return back to the document to continue word processing. A very similar example was demonstrated by Miguel de Icaza, the lead developer of the GNOME project at a LinuxWorld Expo. He used Gnumeric, the GNU spreadsheet software, to show that a vector graphics component could be embedded into a spreadsheet.
The second effort that is of some importance is the wrapping of Bonobo interfaces into GTK-based wrappers, which make it both easy and simple for developers to use existing code and programs with Bonobo components. With respect to these interfaces, Bonobo tries to solve the biggest problem of component-based technologies—object lifetime management and object functionality discovery. These relate to determining if a component which can do a required task exists. The process involves determining whether the component exists (lifetime management) and what the component can do (functionality discovery). More details on the nature of these operations can be obtained from GNOME sites.
Among the projects that use Bonobo and the component object model, the most advanced project is undoubtedly that of Gnumeric—the GNU spreadsheet. It cleanly supports embedded components and can also act as an embeddable object. The other projects that are attracting some attention are Gimp 1.2 which promises Bonobo support, and Evolution and Nautilus (www.helixcode. com). Evolution is a MAPI client that’s designed to perform like Outlook Express. This tool is heavily based on component-based architecture and is still in developmental stage. Nautilus is the new version of the file manager on GNOME (currently GMC or GNOME Midnight Commander). This was demonstrated recently, and shows remarkable promise in terms of ease of use. This shell to the Linux file-system supports both different levels of user interaction (Novice, Intermediate, Hacker, etc) and also different levels of abstraction (for example, file, icon, document and actual text as different views of a word processor document). This project has the potential to reduce the steep learning curve that confronts the average user entering the world of Linux.
For Linux to achieve greater acceptance in corporate circles, elements such as a component model are of vital importance. Even though Bonobo is still classified as unstable code at ftp://ftp.gnome.org/pub/GNOME/unstable/sources/bonobo/, (a stable release is expected with the August release of GNOME), it still represents a major tour de force for the Linux community. To establish and implement a standard of this magnitude is no small task. It reflects the maturity and far-sightedness of a community that not only looks at the past for inspiration, but to the future with anticipation.