This document builds on the ideas proposed in Mike Pilone's KDE-PIM Roadmap. As mentioned in that document KDE has advanced considerably, both in terms of architecture and applications. However, the KDE-PIM framework has remained relatively fragmented. Initial discussions have led to preliminary designs using a central KDE-PIM Server. This server would provide core PIM functionality, as well as a transparent local vs. remote data store. This paper expands on that idea to attempt to provide that type of functionality to all KDE applications, in the form of an application server.
For those not familiar with the application server, distributed application approach I'll provide some
background. In the traditional application model applications are completely self contained executables
interacting with the "outside world" through some type of network connection or storage facility, be it
flat files, DBs, etc. This model was extended to use shared object libraries, or DLLs. Common functionality
was shared between applications through underlying system libraries, for example, libkdecore.so
.
The next step was to provide larger pieces of application functionality, or components, to multiple
applications. This lead to the initial version of KParts/Bonobo. Components were made available to
applications via Corba. This had several problems mostly related to the complexity introduced by
the Corba based architecture. To simplify development and increase performance Corba was removed from the
KParts architecture and replaced with a shared library approach. This allowed components to be loaded
dynamically by an application.
However, the magic happens when you realize that the application doesn't need to know the specific
component it is loading. Rather, the application knows what type of component it wants and
asks a service to provide it. For example, the application can request a component that can edit a text file.
In KDE this locator service is the KTrader
. KTrader
will then find a component
that says it can edit text files and return the component to the application. From the application's
perspective it has simply received a component that implements the TextEditor interface, it does not know
which component is actually being used. To the user, this means they can have a full featured word
processor for editing text files, or good old sed
.
While the component based architecture is extremely flexible, it isn't the end of the story. The latest advances in component architectures venture into distributed components. This is basically a matured version of what was originally attempted with Corba. Currently Enterprise Java Beans (EJBs) and Microsoft's DCOM, now .NET, provide a truely distributed component architecture. What's coming around the corner, however, is distributing on a larger scale. This is the idea behind .NET, and somewhat less formally being pursued by some EJB enthusiasts.
What do I mean by distributing on a larger scale? I mean larger in terms of functionality. Rather than having a relatively thick application that requests components to provide very specific functionality the application becomes a relatively thin client and the application itself is distributed amongst various machines, or at least various components on the same machine. Instead of asking for a component that can edit text files, the application may ask for the Calendar Service then provide a thin GUI on top.
So how does all this apply to KDE? Several problems are brought to light by the proposed KDE-PIM solution:
This approach offers several benefits:
Actually, most of the above functionality is already available using an EJB application server. Microsoft provides their implementation of this type of functionality using MTS, and expanded in their upcoming .NET framework. However, as has been pointed out to me several times, KDE is implemented in C++. Unfortunately, to my knowledge Corba is the only C++ compatible solution that would be able to offer anything close to the functionality described above. Corba has already been demonstrated to not be viable for the average KDE desktop (as well as developer). And obviously MTS is not a solution. So, that pushes back towards EJB, or writing our own app server. I have to discourage writing a KDE specific app server given all the options currently available and the need to begin developing applications based on this framework. However, given the current cross language capabilities of DCOP it would be very possible to extend DCOP to support a common cross language protocol, specifically SOAP. KDE development could continue unabated in C++ continuing to use DCOP to make method calls on registered objects. However DCOP would delegate these calls to the newly created app server. In addition, given the excellent java bindings to KDE/Qt, it would be possible to develop a KDE application completely in Java and make use of the real EJBs provided by the server.
In theory, if the application server spoke SOAP and DCOP spoke SOAP the interoperability would extend well beyond distributed KDE applications. In theory a KDE mail program could use a Microsoft .NET backend, or a Windows user could use Outlook to talk to the KDE mail service on the application server. The Gnome folks could build a completely different GnomeMail, but all would use the same back end. Write a Java front end and take your Mail program with you onto any platform that supports Java.
While I'm very excited about the above ideas, there are several potential problems:
Obviously this approach would need to be expanded and developed further before any long term decisions can be made. However, this could prove to be quite an impressive accomplishment for an Open Source project and push KDE/Linux into an industry leading role. This would not only keep us competetive with .NET, but allow us to leverage any success .NET may have by integrating with services others may offer.
Please feel free to provide any comments, questions, clarifications, or general complaints to Dan Pilone, and thanks for taking the time to make it to the bottom.