Re: Plans for 2.20

["William Jon McCann" <mccann jhu edu>]

On 3/7/07, Rodrigo Moya <rodrigo gnome-db org> wrote:
> On Wed, 2007-03-07 at 13:01 -0500, William Jon McCann wrote:
> > Hi,
> >
> > On 3/7/07, Rodrigo Moya <rodrigo gnome-db org> wrote:
> > > On Wed, 2007-03-07 at 17:16 +0000, Sergey Udaltsov wrote:
> > > > Rodrigo,
> > > >
> > > > > we already do dbus interaction, so it shouldn't add performance
> > > > > penalties at all.
> > > > Ghm, so far IIRC dbus interaction was minimal - just initial "kick" of
> > > > the g-s-d from the session manager - and one request from the keyboard
> > > > indicator (if present). Your proposal to move all interaction between
> > > > g-s-d and its modules onto DBus street (did I understand you right?)
> > > > would put slightly heavier traffic on it, wouldn't it?
> > > >
> > > yes, you understood wrong :) the communication between g-s-d and its
> > > modules would be done in-process, since g-s-d would load the
> > > GnomeSettingsModule implementation from .so (or, for the already
> > > included in g-s-d, they could even be compiled in)
> > >
> > > The D-Bus communication is for 3rd party apps, like, for instance, a
> > > media player that wants to disable the screensaver. That app would just
> > > need to call GnomeSettingsDaemon.disableModule ("screensaver")
> >
> > Why?  We have an Inhibit API for that.  Furthermore, disabling is
> > certainly not what you want to do...  What are you trying to do?
> >
> ok, the screensaver was a bad example :-) Think we have several
> services, and that one app needs to disable them for some reason, if we
> have a separate D-Bus interface for each service (or another different
> thing, because some people might want to use $whatever instead of
> D-Bus), the app would need to use $n D-Bus interfaces/custom solutions.
> Having a single way to disable services would allow that app to do:

I think that until you actually define the problem you shouldn't look
for a solution.

>         for serv in services do
>                 gsd.disableService (serv)

I can't imagine a single application that would have to do something like this.

> Of course, now we need to find what services there would be apps willing
> to enable/disable on demand. Right now, I can only think about the
> screensaver, and so I can't really justify this, since for one service
> there is no need for an extensible solution. But I've heard many times
> people complaining about 'another daemon being added to GNOME' that this
> would solve very easily.

No I don't think this does solve that problem.  I thought you were
only proposing an API.

> Right now, for instance, I've got these running on my system: beagle,
> screensaver, power manager, keyring, vfs-daemon, application-browser,
> gnome-volume-manager, mapping daemon, galago-daemon,
> gnome-typing-monitor, and other people could add more I guess.
>
> I'm not saying this solves the need for daemons, but I'm sure some of
> those could benefit a lot, at least in the code reuse part, from a
> simplified and extensible architecture

Some of the time the people who complain don't know what they are
talking about.  Are there some daemons that can be combined, maybe.
Let's look at some specifics.  You mention:

beagle:
    * this is going to be pretty heavy whether it is its own daemon or not
    * don't know much about it

gnome-screensaver:
    * it should always be a separate daemon for security and stability reasons
    * needs to be able to run outside of GNOME sessions in some cases
    * if you don't install themes then the daemon uses very little
memory (for a GTK app)

gnome-power-manager:
    * needs to be able to run outside of GNOME sessions in some cases
    * similar in scope to gnome-volume-manager

gnome-power-manager:
    * similar in scope to gnome-volume-manager

gnome-vfs-daemon:
    * 572 KiB writable memory

gnome-keyring-daemon:
    * 108 KiB writable memory

mapping-daemon:
    * 88 KiB writable memory
    * is started on demand

gnome-typing-monitor:
    * entirely optional
    * could be part of gnome-settings-daemon

Perhaps gnome-power-manager and gnome-volume-manager can be combined.
They are both pretty similar.  The new thing might be called
gnome-hardware-agent.

It is worth noting that when you try to optimize for memory (by
conglomerating tools) there are often serious tradeoffs.  Stability
may be impacted.  You may end up using more memory because a daemon a)
is not free to die when unused or start on demand b) may have to use
more threads or subprocesses to still do things concurrently.  There
is also a "tragedy of the commons" type problem when tools are
combined when the maintainership is unclear - look at the history of
control-center.

In any case, I don't think any of these problems are able to be solved
by trying to define some GSD API for services.  And in particular I
don't think you ever want to disable any of these things except
perhaps the typing monitor.

I think it is best to try to separate the problem of capplet and
control-center shell design from the perceived too many daemons
problem.  For example, maybe in the end we end up with screensaver and
power-management preferences in the same dialog but the power-manager
and volume-manager daemons in the same process...

Jon