Daemon or no daemon

Magnus Bergman magnus.bergman at observer.net
Mon Apr 18 17:52:02 EEST 2005


I've repeatedly read discussions about weather to use a daemon or not.
First related to DConf (and Electra) and more recently related to D-VFS.

I stood before the same decision in a similar situation some year ago
and now I realize how I should have solved it the right way, to get the
best of both worlds. This is a general design and applies both to DConf
and D-VFS design discussions.

Some back-ends doesn't need the daemon, or can not benefit from it. In
situations then the no back-end needs the daemon, it doesn't need to
run. Those special cases then the daemon isn't needed could be:
* No application needs the features of the daemon.
* All back-ends in use can provide the features of the daemon.

The solution

The solution is to have the same API for communication with the daemon
as for communication with the back-ends directly. This is simply done by
using the same library. What the library does is to decide which
back-ends to use and when. This functionality is used by both
application and the daemon, so they link to the same library and use the
same API. But only the daemon uses the library to call the back-ends
which needs the daemon.

                              | Daemon-link back-end |
 ,-------------,  ,---------,/`----------------------'
 | Application |--| Library |
 `-------------'  `---------'\,----------------------,
                              | Some other back-ends |                  

 ,--------,  ,---------,  ,------------------------------,
 | Daemon |--| Library |--| Back-ends needing the daemon |
 `--------'  `---------'  `------------------------------'

What is needed is one API for the library and one for the back-ends. And
possibly a standard way to start the daemon (if the library should be
able to do that). The implementation of the daemon and it's IPC
mechanisms becomes independent.

More information about the xdg mailing list