Re: Plans for 2.20

[Rodrigo Moya <rodrigo gnome-db org>]

On Wed, 2007-03-07 at 16:33 +0000, Sergey Udaltsov wrote:
> Rodrigo,
> 
> First question: what would be the performance penalty? I know some
> GNOME developers spent huge amount of time optimizing the startup
> sequence and minimizing the statup delay. What kind of performance hit
> do you expect introducing DBus interaction?
>
we already do dbus interaction, so it shouldn't add performance
penalties at all. In fact, we would reduce login time by putting all
xrdb calls together, for instance

>  As an alternative - could
> g-s-d become build-time modular rather than runtime modular? What
> would be the advantage of the runtime modularity here? Do you expect
> any particular modules which would be delivered outside of g-c-c
> package?
> 
I was thinking on screensaver and power manager. Those are not really
user apps to be started at login time, they are more services. And once
we all agree in having this daemon (probably outside of the
control-center module, I guess), it could be used for any desktop daemon
you can think of (vfs-daemon, screensaver, power manager, etc, etc)

> Providing some DBus interfaces for external apps sounds like a
> reasonable idea - but moving internal g-s-d interfaces to DBus looks a
> bit questionable, performance-wise.
> 
> Please understand me right - I am not saying your idea is totally
> wrong, I am just having some doubts and asking you to resolve them.
> 
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.

> > There is still the question of what to do with the current D-Bus interface for the keyboard.
> What's the problem with it? It would be implemented by the keyboard
> module, wouldn't it?
> 
well, if the keyboard module is that, a module, I haven't thought of a
way for modules to "install" methods to be called via the D-Bus
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, apart from being
unneeded, having already a D-Bus server running in the same process.

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