Re: GNOME 2.10 module proposal: libnotify and notification-daemon
- From: "John (J5) Palmieri" <johnp redhat com>
- To: Nielsen <nielsen memberwebs com>
- Cc: desktop-devel-list gnome org
- Subject: Re: GNOME 2.10 module proposal: libnotify and notification-daemon
- Date: Mon, 08 Nov 2004 16:41:42 -0500
On Mon, 2004-11-08 at 15:18, Nielsen wrote:
> Rodrigo Moya wrote:
> > On Sun, 2004-11-07 at 12:06 +1100, Jeff Waugh wrote:
> >>GNOME has a buttload of difficult to understand daemons. If one fails, or
> >>can't start, it is hard for an administrator to know what's going wrong or
> >>what it will affect.
> > it would be probably a good idea to have gnome-session be pluggable, so
> > that 3rd parties can write extensions for it for extra daemon-like
> > processes to be started. Thus, gnome-session would just have to load
> > those extensions and call a known entry point on them.
> > That, or the number of daemons will continue growing :)
> I'd just like to chip in and say that I've been wondering about this
> myself. I'm the maintainer for seahorse which installs an 'agent' daemon
> Currently it seems (could be wrong here) there's no way to have a daemon
> start and install environment variables in the users session.
You can't install environment variables unless you are the parent
process. DBus does this by spawning the xsession with dbus-launch.
> I think
> DBUS does this somehow, but having some sort of plugins into
> gnome-session would make this possible apps that don't come with the
> distro. It would also make supporting multiple sessions for the same
> user much easier.
I think I agree with Havoc in saying that in-process plugins within
gnome-session is a scary thought being that any buggy third party plugin
can cause a system to not be able to log into the desktop. I myself
have come to the conclusion that a growing number of daemons is not such
a bad thing with dbus-activation in the picture. I am writing a dbus
policy manager framework proposal that would provide libraries for
creating policy daemons that could manager their life cycle
intelligently using dbus for activation (almost like an xinetd for your
session). It would also provide a callout daemon that could respond to
dbus messages by running a script (similar to how HAL does callouts).
This will cut down on the need for a daemon for simple things (we might
even be able to cut down g-v-m into a set of callout scripts).
John (J5) Palmieri <johnp redhat com>
] [Thread Prev