13.2. History

The UNIX programmer doesn't lack choices when there's need for interprocess communication. KDE made (and still makes) use of many of the possible technologies: pipes, sockets, X Atoms, temporary files, shared memory, CORBA, and RPC.

From a historic point of view, however, in the beginning the developers were less preoccupied by building communication means into the burgeoning code base. When information (data or commands) were to be passed around, UNIX pipes or even common temporary files were used.

With the KDE window manager—named kwm in its first iteration—becoming more mature, a more consistent need appeared for collaboration between applications. A mechanism based on X Atoms was thus introduced by kwm's author, Matthias Ettrich. This was used until the 1.1.2 version of KDE. The X Atoms are C language structures, defined and implemented in the X library. They are used by X Window as a convenient and rapid means of passing data between X clients (applications) and the X server, as well as between different X clients. Given their rather simple nature—that is, designed to answer specific needs that the X technology encounters—X Atoms have intrinsic limitations in terms of the size of data they can transfer as well as in the flexibility and complexity of the information passed through.

These limitations convinced the developers, even in early stages of the code, to search for better communication solutions. The CORBA journey and then DCOP came as a result of this search. Yet the X Atoms are still used in the second version of the KDE API, in conjunction with X ClientMessages, in the form of KIPC (see kdelibs/kdecore/kipc.h in the code base). This is a very simple and thus very efficient communication mechanism created by Geert Jansen. KIPC allows sending messages such as "just changed" messages related to most common desktop settings that have to be sent to all the KDE-enabled applications. A good example is the "color palette just changed" message that the Control Center sends to all KDE applications when the user chooses a new color scheme.

For a rapid but complete understanding of KIPC, you can study the approximately 150 lines of effective code that constitute the inner details of this simple communications mechanism.

Since 1997, when work started on KOffice and other complex KDE applications, developers have started to create a fairly functional implementation of CORBA (see http://www.omg.org). CORBA (Common Object Request Broker Architecture) is a complete, complex communication structure built to become an industry standard, capable of networked, cross-platform, reliable communication between any applications that subscribe to the standard.

Functionality
Completeness
Availability
Robust C++ bindings

Any combination of these is also why other implementations (such as the oft-proposed Orbit) were ruled out.

The satisfactory results generated by the more than year-long CORBA experience of the KOffice developers were used, in late 1998, to merge this technology in the central KDE libraries. Alas, CORBA brought other limitations—and with these last evolutions to completely embrace KDE, these limitations became obvious:

CORBA was too complex for the requirements of the desktop paradigm.
The dynamic character of a desktop became hindered by the static nature of CORBA.
It was difficult to convince developers of small applications that they had to read and understand thousand-page manuals before they could enable interprocess communication in their projects.
Compilation of the CORBA-enabled code base was very time-consuming and resource demanding.
MICO had performance problems including high CPU usage and large memory consumption.
The stability of the resulting applications wasn't satisfactory.

A discussion started in the developer community that continued long after the final "let's forget CORBA" decision. This discussion resulted in the conclusion that this communications technology came with too much hassle compared to the gained benefits. One more element has to be added to the picture of the KDE inter-application communication situation as depicted shortly before the creation of DCOP: all the described technologies were present and used in the KDE code base simultaneously. Also, developers often found limitations or large development difficulties that were forcing them to create workarounds to fit their needs. For example, MICO was making use of STL (the Standard Templates Library), which was not portable enough for KDE and also had important performance problems. In order to solve these problems, a large amount of effort was invested by Simon Hausmann, Torben Weis, Steffen Hansen, and many others to replace STL with QTL (the Qt Templates Library) in KDE's CORBA. At a given moment, the heterogeneity of the communication solutions and the growing pains of keeping all issues properly handled became obvious.

In this landscape, KDE developers Matthias Ettrich and Preston Brown engaged in a high-pitched development effort and created DCOP. This event coincided with the big KDE-TWO reunion, held in Erlangen, Germany, in October 1999. A new, better era thus began. An important step forward in the accomplishment of the protocol and its advanced functionalities was achieved during the third coding reunion of KDE developers, during the month of July 2000, in Trysil, Norway.

DCOP is released as free software. Based on largely available technology (ICE, the Inter-Client Exchange mechanism, available with X Window) and reasonably separate from the KDE technology, DCOP is intended as a generic interprocess communication technology. The authors keep faith that, given its qualities and the feeble resource usage, DCOP will soon become a widely spread commodity protocol.