rfc: gnome-inetd

[Sean Middleditch <elanthis awesomeplay com>]

We've got several nifty new listening-type daemons in the GNOME
framework being proposed lately, and several other long-standing
daemons.  Examples are things like gnome-user-share, chat programs,
music sharing services, VNC, and so on.

These programs currently work in one of two ways - either the user
enables the daemon in their preferences and it starts up at login time
and shuts down at logout time, or the user has to explicitly start the
app (which might be done by the session manager).  Apps that must be
started generally clutter the screen with all sorts of windows or icons
that really aren't needed most of the time (they are often little more
than glorified configuration panels), and tend to be a mess - I often
don't start apps like instant messengers simply because I don't want the
window around (and don't have a notification area to be abused).

For session-long daemons, like gnome-user-share, these daemons are
started and just sit there doing nothing most of the time.  These
daemons take up memory, or simply offer a big drag on system startup
time.

Additionally, adding new daemons can be a pain, because you have to
actually write a daemon.  Making a true daemon (especially with session
management and so on) can be a *serious* pain.

I'm thinking that perhaps something like a gnome-inetd would be a good
idea.  This itself doesn't even really need to be its own daemon, it can
certainly just be functionality included in another daemon.

The idea is that there are a list of commands port in GConf.  The daemon
reads these and listens on the ports - when a connection comes in it
launches the command, redirecting standard I/O to the new process.  Just
like inetd, for the most part.

Best of all, because this is managed by GConf, administrators have
control.  They can mandate that some services are always on (desktop
sharing, which admins probably use the most) and others are always off.
Configuration dialogs for various services would simple mark an enabled
or disabled flag for services for users to turn them on and off (if they
are allowed to).

The only downside to this system over having all those daemons floating
around is the potential performance problem.  Spawning new processes for
each new connection can be fairly heavyweight.  Fortunately, desktop
services don't usually serve a large number of users, and many of the
interesting protocols don't need a lot of reconnecting (even for things
like web sharing, browsers tend to reuse existing connections these
days).

So... thoughts?