Re: Plans for 2.20

["Sergey Udaltsov" <sergey udaltsov gmail com>]

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?

> 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?

> 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?

> 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?

> 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.

> 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.

Regards,

Sergey