Re: Plans for 2.20

[Rodrigo Moya <rodrigo gnome-db org>]

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")

So, as you can see, the D-Bus traffic would be minimal, just in sporadic
uses.

> > In fact, we would reduce login time by putting all
> > xrdb calls together, for instance
> How happened they are separate now? I see gnome-settings-xrdb.c in
> SVN. Is there anything else?
> 
yeah:
gnome-settings-font.c
gnome-settings-xrdb.c
gnome-settings-xsettings.c

> > I was thinking on screensaver and power manager. Those are not really
> > user apps to be started at login time, they are more services.
> So, you are effectively killing standard good old execution semantics
> here, and introducing DBus-driven invocation. This can cause some
> maintenance and support problems, I'm afraid. Do you have in mind some
> list of advantages it would give to either g-s-d or session manager or
> these apps/services? Effectively, do not you turn g-s-d into another
> session manager?
> 
no, it's an app that starts GNOME services. That is what it does today,
although in a very messy way. Not sure if the screensaver is a good
example of an external app to use this mechanism though

> > control-center module, I guess), it could be used for any desktop daemon
> > you can think of (vfs-daemon, screensaver, power manager, etc, etc)
> Well, if we go this way - why not take one step further and
> standardize these interface on fd.o level - so the services would be
> accessible not to g-s-d only but also to, let's say, XFCE?
> 
it makes sense to me

> > yeah, maybe those public interfaces should not be public. But I was
> > thinking about uses like a 'services' capplet to enable/disable them,
> > apps that disable the screensaver (movie players, for instance). So
> > maybe we should really think what 3rd party apps would need and make
> > them public or private based on that.
> Well, this interface (listing/enabling/disabling services) is between
> g-s-d and external apps/capplets - there may be real reasons to make
> it public (or public to some extent). But this does not imply that
> interface between g-s-d and its modules should necessarily be public
> (or even exist, from DBus POV).
> 
> > interface. That is the "problem". Of course, we could always have
> > another D-Bus server started in the keyboard module, but that would
> > break, somewhat, the modularity I was aiming for,
> Would it? IMHO It would really make modules more independent and
> loosely coupled with the g-s-d core. But anyway - it you implement the
> interface between modules and g-s-d core as usual C interface (as
> opposite to DBus interface), you'd easier be able to share single DBus
> server instantiated by the core.
> 
yeah, that's what I was suggesting :)

> > On the other hand, it wouldn't be difficult to provide a way for modules
> > to "install" those methods to be called via the g-s-d D-Bus interface
> I am not sure I understand how you are going to do it... May be, it is
> just my ignorance with DBus technology
> 
> I hope my questions are useful and help us both to understand and
> refine the final solution.
> 
yeah, me too :-) My real aim is to clean g-s-d, which I've tried to do
in the last 2 or 3 releases, but I've always found the need for a better
structuration of the code, to allow it to grow and, much more important,
to be much simpler than what it is today.
-- 
Rodrigo Moya <rodrigo gnome-db org>