Re: Plans for 2.20

[Rodrigo Moya <rodrigo gnome-db org>]

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:

	for serv in services do
		gsd.disableService (serv)

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.

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
-- 
Rodrigo Moya <rodrigo gnome-db org>