Re: GNOME 2.10 module proposal: libnotify and notification-daemon

<quote who="Mike Hearn">

> Pros for a separate daemon:
> - reliability/robustness
> - works better with selinux
> - that's how it's actually written, though it could be adapted easily
> - can be activated by dbus-daemon on demand
> Cons for a separate daemon:
> - extra startup time needed to create a new process
> - Jeff mentioned "fewer moving parts better for administrators" though
>   not being an administrator I don't really understand this ...
> - "ps ax" is kind of messy when you have a ton of daemons, but then we 
>   already do have a ton of daemons so it's kind of a moot point.

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.

The abstract idea of "a separate daemon makes it more reliable and robust"
does always not apply in practice - what does an admin do when a user's
desktop flashes up the right theme, and then goes back to the default theme,
and no longer lets her change it? When the admin finally figures out it has
to do with gnome-settings-daemon, they have to find out why it's failing...
and then fix it. When we talked about this on IRC, I asked if anyone knew
what mapping-daemon did -> no one knew. :-) [ It's used for burn:/// ]

Although it could be argued that the notification area is unrelated to the
notifications sent via libnotify, having it handle and display notifications
would make sense. No applet, no notifications. Easy for users and admins to

- Jeff

-- 2005: Canberra, Australia
   "Odd is good by the way. I knew normal in high school and normal hates
                            me." - Mary Gardiner

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]