KDE—The Next Generation
When starting the development of KDE 2.0, the KDE team was focusing on using CORBA, the Common Object Request Broker Architecture, a middleware framework for distributed object communication. However, during development it turned out that while CORBA is a cleanly designed architecture useful for large and high-latency things such as corporate databases, it is not so well-suited for tasks such as user interfaces where speedy responses are needed. There are several reasons for this. CORBA is distributed in nature, which is very good if you need distributed objects, but more of a burden than a gain if you don't need them—and you don't need them in an office suite. Also, CORBA is too static. In a desktop, objects and applications come and go all the time. This is very hard to track reliably with CORBA.
Thus, the KDE team had to find something else in two areas. KOffice needed a new underpinning for embedding applications into each other and general desktop communication between the control center and the applications. Something more lightweight was needed, and this led to two new inventions that are now used in KDE 2.0: KParts and DCOP.
KParts is the new object framework used in KOffice for embedding application windows into each other. You can, for example, embed a spreadsheet window from KSpread into the word processor window from KWord, just as you could with the previous development versions. Since all KOffice components are now simple shared libraries and the whole document is handled in the same process, this happens much faster and smoother than before. Actually, the previous embedding framework was so slow (and buggy) it was hardly ever used. With KParts, there is no speed difference between working on the container part (the word processor in our example) and the embedded part (the spreadsheet in our example). In addition, embedded views can now be tilted, twisted, rotated and sheared, something which to our knowledge is not available on any other platform. I'll talk more about KOffice a bit later in this article.
DCOP, which stands for Desktop Communication Protocol and is pronounced “dee-cop”, is the other new communication facility. DCOP uses a standard mechanism, ICE from X11R6. ICE was written mainly by the X developers to implement session management, but as it turned out, it can also be used for other things. Since it is standard, available in all X11R6 implementations (including XFree86), fast and lightweight, it was a natural choice. For those interested, communication between processes in ICE is done via either UNIX domain sockets, TCP/IP sockets or DECnet. DCOP is just a thin layer on top that handles the marshaling of data and makes sure all communication streams reach their destination. You can imagine DCOP as a traffic cop who stands in the middle of a road crossing and directs the cars into their lanes, so that everyone reaches their destination, no accidents occur and no passengers end up in the wrong cars. (Okay, this is where the analogy breaks down.)
DCOP is used in KDE to unify the different communication means, like X atoms for communication between the control center and the application or TCP/IP sockets. In KDE 2.0, developers need to learn only about DCOP and can forget about X atoms and other communication means. Also, since DCOP is based on the X11R6 standard ICE and is open and documented, it is not bound to KDE. Non-KDE applications that wish to take part in these communication channels can either link directly to the KDE implementation of DCOP or easily implement a compatible implementation themselves. Also, there is already an XML-RPC-to-DCOP bridge, and people are working on a general IIOP-DCOP bridge as well. XML-RPC is especially interesting, because it will allow scripting the whole desktop from just about any language you like, including /bin/sh.
This does not mean KDE has completely dropped CORBA; the KDE team just has a much more judicious view on where CORBA is useful and where it is not. There are areas where CORBA is still deemed useful; one of them is the new KDE multimedia framework aRts.
In the current version, aRts is an audio server and mixer that can handle many different incoming audio streams, manipulating, mixing and outputting them to an audio device like an ordinary sound card. At the KDE developers' conference KDE II in early October in Erlangen, Germany, aRts' main author Stefan Westerfeld gave a very impressive demo of aRts mixing two MP3 streams: one of them manipulated with additional sound effects and one synthesized in real time from the MIDI events being played on a MIDI keyboard.
Again, CORBA has to be used judiciously. For a full-blown multimedia application like Brahms, the KDE synthesizer, CORBA is the right tool. For a non-multimedia-oriented application that just wants to play a warning beep when something goes wrong or a lengthy background task is finished, CORBA is way too much, especially since this application would have to link to the full CORBA machinery just to play its beep. This is why aRts also provides a lightweight, raw TCP/IP-based mechanism for playing simple .wav files. (The applications cannot do this themselves because on Linux, only one application at a time can open a sound device.) Also, the KDE team is evaluating another alternative, MCOP, the Multimedia Communication Protocol. By the time you read this, it may have turned out that MCOP is better suited for this task than CORBA, and if it is better, then it will probably already be in use for aRts.