Basic idea
Currently XFce lacks a consistent and easy to use architecture for configuration handling (sure, we have MCS but thats only ment and usefull for a few desktop specific setttings, not for general application settings), MIME handling and general desktop IPC. That says, every application that wants to store settings has to implement parsing and storing of configuration files and has to parse the configuration files atleast once on every startup. This might look ok for the small number of programs currently shipped with the XFce 4 distribution and putting common code in libraries looks like a good way to go. But in reality this approach is usually too shortsighted.
During the 4.0 development cycle I started to think of ways to bring MIME support to XFce and I came across the idea of letting a separate daemon process handle such things. Therefore a client - an actual desktop application - sends a request to the daemon using a fast and flexible transport layer and the daemon does the required computations and sends a response to the client. For example, an application could sent a request like "Give me the value of the setting xfce.desktop.background" and the daemon would lookup the configuration setting and send a response with the value or an error message if the setting does not exists.
The client part of the protocol handling would be hidden
behind a well-formed API.
Design ideas
Heres my first idea for the design of what I call XFce all-in-wonder architecture
(suggestions for better names are welcome). Separate the whole
architecture into different layers to reduce complexity. 
[PostScript] [Dia]
The transport layer should be implemented in libxfce4util both the daemon
and the application/library part. The modules will be implemented as
shared object files which will be loaded by the daemon on-demand and
automatically unloaded when no longer needed. The transport protocol
should be made very flexible so that new features like advanced desktop
IPC or even MCS can be added to this framework by just writing a new
module for the all-in-wonder daemon and a new component for the
application part. Modules should also be able to plug in new data paths
into the framework like for example Shared memory IPC or similar
technologies.
Why?
First of all, XFce is missing a basic architecture for handling what I would describe to be cacheable objects and desktop bound interprocess communication (as you can see, I am a bad linguist :-). While new applications are added to the desktop, code is copied - for example libxml code for configuration handling - from some other application, modified and then used within the new application. Currently there aren't that much applications but XFce becomes more and more popular and its only a question of time when new applications will be added. They're developers will follow the tradition of copying/modifying/using code from existing applications and one need no software engineering skills to see that this will become a maintain nightmare. So two options are left - there are other options, but I don't consider them to be usefull -, either put all common code into libraries or develop a new framework using a client/server concept. Putting all common code into libraries is dangerous within open source projects, since most of the time this results in either a small number of huge libraries with lots of unused functionality or lots of small libraries with complicated dependencies. Each of which is hard to maintain, though this techniques are quite common in open source projects - just look at Gnome and KDE - and the result is what users usually can't describe, but instead they name it BLOAT.
So, lets look at the
architecture described above. What makes it better than the shared
library approach?
- Small interface libraries. That says the base libraries
contain only the code to interface with the transport layer and the
communication protocol, not the actual implementation logic. Though
runtime link editors were improved in the last years, relocating shared
objects is still an important factor when it comes to startup time, and
thats why big fat libraries are bad besides other points such as
decreased maintainability.
- Possibility of caching objects. Having each application parse files itself its quite hard to implement caching of objects, such as configuration nodes. This could speed up startup quite a lot; imagine, the whole configuration has to be parsed - or loaded otherwise - only once when the daemon is fired up, that is on session start, and each time a client needs configuration settings it does not have to parse a config file, instead it simply requests the required settings from the daemon.
- Desktop bound interprocess communication (a bad name,
indeed :-). This could be implemented quite easy by writing an IPC
module and a library interface, where the IPC system allows clients to
register as IPC entities and
send messages to each other. A simple example where such a mechanism is
usefull would be if you want to allow only one instance of an
application or for the mixer. Here, there would be some kind of mixer master and the panel plugin
and a standalone mixer would communicate with this master using the IPC
system.
There are several other advantages and several other problems that can solved using such a framework and on the other side there are some drawbacks and disadvantages nevertheless, but I won't discuss them here currently. All in all, the described system can be seen as some kind of fast Message Bus system and its only a first time design. Its open for discussion. If you want to share some valuable comments about the ideas described here, feel free to send mail to xfce4-dev at xfce dot org.
Benedikt Meurer, 2004/01/15