Exploring: Fighting Daemons goes against the practice of having separate daemons in GNOME.
This approach is used by KDE, with its
kded session daemon. I hate it because once one of the mini-daemons fucks up,
kded simply goes AWOL, and things start to go awry in the KDE desktop/session. This is only an example of how consolidating multiple daemons in a single process is bad for software quality.
What should be done is constify and make the entire GNOME library stack shareable as much as possible. Then startup cost will be reduced by a factor of N, where N is the number of daemons that are going to be started up. Plus, investing efforts in this direction will benefit the entire GNOME app stack. After all, Linux and other UNIXes are stars in
fork-land. Plus, once one daemon is already started, the others don't even have to hit the disk for the libraries (and won't have any startup overhead, assuming maximal startup cost reduction).
Even then, lots of programs dynamically link to unneeded libraries, which can be pared down in the
autoconf/build process (why should most GNOME daemons endure the FreeType library startup cost?). The autopackage guys have gone a long way in identifying these issues and providing real solutions to this problem.
And one process per daemon means you gain more software reliability and quality.