by Cristian Tibirna
One major reason for the rampant dependence upon computers is their capability to greatly simplify the work and life of users. This capability is largely a consequence of the computers' "education"; that is, their programs. The educators (that happy bunch we love to call the hackers) discovered that sociology applies to computer programs as well as people. In order to behave as worthy citizens of a computer, the programs need to know how to communicate.
A long time ago, the UNIX fathers noticed the hunger of programs for communication. Therefore, they invented the genial pipes. Arguably, most of the force of UNIX comes from offering its users the ability to build combinations of small tools. These combinations can reach a potentially infinite complexity. These "metatools" help the user easily accomplish complex tasks. Pipes are an essential ingredient in these combinations. You have probably used, at least once, commands such as
1 2 ]~> find . -name "*.cc" | xargs wc -l 3 4 ]~> cat /etc/passwd | awk -F: 'print $4' > /tmp/users-realnames 5 6 ]~> echo "What a happy world!" | mail -s "Oh yeah!" email@example.com 7
Today, we want to develop programs with nicer faces and better capabilities, and we rediscover that communication between applications is essential. Yet, in the time of graphical interfaces, point and click, and what you see is what you get, it is less convenient to use traditional pipes. More advanced communication means are needed.
Thus appeared DCOP, the Desktop Communication Protocol. This name designates the set of tools that KDE programs use to pass information between them.
This chapter describes the programming interface that DCOP defines and gives a few directions and examples.
The K Desktop Environment was designed from the very beginning as a collection of programs, each targeted at resolving a strictly delimited category of tasks. However, the main goal of a desktop environment is to offer the user a unified way of functioning that preserves or even enhances his productivity in a heuristic way, despite the diversity of tasks the user has to accomplish. The validity of this goal is proven by the wealth of integration tools that proliferated around and inside the traditional UNIX window managers (from the times that preceded KDE).
Those window managers had scripting support and other kinds of programming interfaces. They offered hooks for programs willing to take advantage of the specific windowing information accessible to the window manager or to implement integration with the underlying operating system. There also were connections through which programs could manipulate the window manager.
It was not unusual for most window managers to come bundled with helper tools such as task lists, icon managers, or event handlers that took advantage of special communication functions in order to offer a better experience to the user of the graphical interface.
In running KDE, the need for communication between applications stands out. Here are a few examples of interprocess communication needs:
Communication is essential even between distinct instances of the same application. Starting with version 2.0 of KDE, the concept of unique application is available. This concept, very simple in essence, stipulates that an application can choose to never have more that one fully running instance. A user can try, of course, to spawn a second instance. It is up to this new process to discover if previous copies are already running. If an older instance exists, the new one should be capable of communicating with its predecessor. Through communication, it would be able to trigger the display of an information dialog box or to pass over the parameters provided by the user, such as the name of a file to open or a special command-line option.
When a given number of applications are in charge of similar tasks—for example, the processing of users' mail—collaboration between such applications is very useful. Imagine, for example, a tiny mail monitor that sits in the background and checks for new messages in multiple mailboxes. In the event of a new incoming message, the monitor should be able to send event information to the system's notification handler (KNotify), check whether there is any running mail agent, and if there is, try to communicate to the mail agent information that will promptly modify its status.
As you can see, building reliable means of communication in the backbone of KDE is necessary. Doing this in such a way that the resulting programming interface is simple, easy to use, and efficient is also highly important. DCOP offers all these and more.