Re: [gpm] Re: Gnome 2.16 Module Proposal: GNOME Power Manager

[David Zeuthen <david fubar dk>]

On Fri, 2006-04-14 at 01:17 +0200, Danny Kukawka wrote:
> On Thursday 13 April 2006 21:52, David Zeuthen wrote:
> > (dropping desktop-devel-list from the Cc)
> 
> Why?

Because a discussion on how g-p-m works is off-topic on d-d-l? The
thread started with whether GNOME would include g-p-m in the 2.16
desktop release and people focused on two things.

> > On Tue, 2006-04-11 at 19:13 +0200, Danny Kukawka wrote:
> > > Btw. I don't understand: What's the problem with a system daemon (with a
> > > well defined DBUS-Interface, with a well defined default policy, without
> > > need a session daemon) specialized to powermanagement. You can use
> > > provided functions, but you don't need to use all available if you don't
> > > need them in g-p-m. The daemon is _complete_ desktop _independent_, I
> > > think this was the whish of Davyd Madeley (* A daemon with no GTK+
> > > dependance that would be suitable for cross-desktop use).
> >
> > Desktop independency for the sake of.. well desktop independency... is
> > just pretty point-less.
> 
> Sorry, I don't understand what you try to tell me.

As I said I think it's *great* to see GNOME and KDE interoperate and I'm
a big supporter of that. But one trend is that people get so eager about
it that they forget what problem they're trying to solve. KDE, GNOME,
Enlightenment and other desktops are different desktops because their
creators have different goals.

> > Here are *some* of the problems
> >
> >  2. It's completely stupid to read system wide settings from a different
> >     location than per-user settings. Code duplication is bad.
> 
> I don't see this problem. The deamon can read his settings from one place and 
> can get changed via the dbus-interface from any connected client. It's 
> complete uninteresting for the client from where the daemon get his settings 
> and also complete uninteresting for the daemon from where the client read his 
> settings. There is nothing stupid.

Look at it as a whole: If I'm a user or administrator I want a single
interface to read my settings from. In particular I don't want to Google
on the net or read documentation that tells me I need to edit some file
in /etc/foobar just to change the defaults. That is just silly.

In other words, once g-p-m is able to run when no-one is logged in (e.g.
system-wide), we simply add a button

 [Make settings system-wide]

and the user authenticates; we write the settings to the default area of
e.g. gconf. We can play other tricks to do this automatically if there
is only one user on the system, only show this button if the user has
certain privileges (group membership) etc. etc. 

If g-p-m relies on e.g. the powersave daemon there is no such guarantee
because it also reads settings from /etc/foobar. Sure, the Powersave
daemon may be changed to not do this but what's the point of the daemon
then?

As I said: the architecture you propose (make g-p-m depend on the
Powersave daemon) encourages developers to do silly things like this
because "it's good enough for now" and "real men edit files in /etc". As
a data point, NetworkManager does silly things like this to use static
IP addresses - it's a *mess* because it's even distribution dependent.

Not to mention a lot of code to get options from several sources. More
code equals bloat, more RAM usage, more failure points, more bugs etc.
And... introducing IPC into the equation only complicates matters
further. D-BUS makes IPC look really easy but most people forget it's
actually real networking and all the corner cases that implies. Have you
ever tried debugging a program that relies on two processes and IPC?
It's much harder than if it's a single process.

With what I'm proposing (enforce all policy in a single desktop session
daemon) you have *zero* of these problems. All your code is in a single
process, no IPC overhead neither in code complexity nor execution speed,
native configuration system (gconf for GNOME, the KDE equivalent for
KDE) is always available etc etc.

> >  3. Having a system-wide daemon encourages very silly things
> >     - read plain text system wide settings from /etc instead of the
> >       default area of your desktop configuration system - what happens
> >       when your desktop configuration grows an LDAP backend?
> 
> Where is the problem? I can't see here any problem ... see above.

So if I'm an admin of a site with 2000 computers I simply use an LDAP
backend for gconf; I tweak one little setting in my LDAP console and my
changes to the default power management policy is pushed out. 

That's one reason it's extremely important to have a single source for
configuration.

> >     - do completely silly things like grepping the process list and
> >       refuse to suspend e.g. when a process named "mplayer", "totem"
> >       etc. is running
> 
> This is IMO not really the primary job of the deamon. The client can do this 
> also. 

Only the client knows. I was referring to what silly things (like
grepping the process list) I've been told the Powersave daemon does...

> The benefit: you don't need to do this in the daemon if there is no 
> client which need this function. In case of KPowersave for example we do this 
> in the client and also only if the user enable it and edit the, for the user 
> specific, blacklist. 

... and things like grepping process lists is a complete hack and not
acceptable. Plastering blacklists into the picture is just another hack
because the first hack didn't work. Do you disagree?

> And by the way: there are really more elegant methodes to get information 
> about running processes than 'grepping the process list' and if it maybe make 
> sense to do this in the deamon - I see no problem to implement this.

The way this works with gnome-screensaver and gnome-power-manager is
that we have inhibitor interfaces in on the D-BUS session bus. 

So if I'm the Nautilus file manager I can simply take a lock on the
inhibitor interface on g-p-m when copying large files, see

 http://bugzilla.gnome.org/show_bug.cgi?id=334806

for details. Similar, if I'm the Totem movie player, I take a lock on
the gnome-screensaver inhibitor interface to prevent the screen saver
from starting. It's *that* simple. There's a couple of other interfaces
planned like being able to do an action before suspend or hibernate (if
I'm a word processor I want to quick-save etc.)

I asked Richard and others to propose on the xdg-list using
org.freedesktop instead of org.gnome. If we can agree on these
interfaces (I'm hopeful but a little pessimistic), then GNOME movie
players will inhibit the KDE screensaver and vice versa. 

> >  4. What if GNOME wants a crack-rock interface in the system daemon and
> >     the KDE don't want this because they don't like so many options?
> 
> Hey, this only a argument to stop all targeted discussion. Take a look at 
> NetworkManager or your own project: HAL. Why do you think there is no way to 
> develop a project together - KDE and GNOME guys? No comment. 

HAL doesn't enforce any policy and the non-desktop-specific parts of
NetworkManager enforces only little policy. I've already argued that NM
should work more like g-p-m. That might happen but I haven't even
proposed this yet.

A think like the Powersave daemon does little more than enforce policy,
in fact I'd argue that it only enforces policy.

> Btw. why do you think KDE developers would have problems with many options? 
> Sounds crazy. 

My point was simply that once you start enforcing policy then you have a
huge difference of opinion between the GNOME and KDE crowds. Do you
disagree?

> >  5. Splitting g-p-m into more than one process will most likely just
> >     complicate the code and introduce bugs. The interface is *not*
> >     simply "upload settings from gconf to system daemon" since you
> >     want to popup dialogs from time to time.
> 
> I know the code. Btw. nobody said: split g-p-m into more than one process. We 
> suggested to share code between the desktops and use _one_ _common_ _cross_ 
> _deskop_ _daemon_ for powermanagement. 

That is effectively splitting what g-p-m does into two processes. Look
above for why this is bad.

> > >  This would be a win-win situation for all desktops.
> >
> > It's great when KDE and GNOME can share specs and software.
> >
> > However, this is kinda an area where we may be too different.
> 
> Sorry, but this is a point I don't understand. Have you ever take a look at 
> the current solution on KDE or on powersave or KPowersave? I taked a look at 
> g-p-m while integration on SUSE and I don't see why you think KDE and GNOME 
> are too different to work together.
> 
> Don't get me wrong, but this all sounds for me a littlebit as if there is 
> always only one way to share projects and code between the desktops - if it 
> is developed for (by) GNOME (developers) (see for example NetworkManager). 
> I'm maybe wrong, but if so: this is sad, isn't it?

Well, KDE developers and GNOME developers have a different view on the
world and that's fine. I'm just trying to respect that instead of
forcing you to use bits and pieces that enforce policy.

> Maybe there would be a way to discuss what is possible instead of what is 
> _maybe_ not possible or problematic. If there are people which are interested 
> in such a discussion: let me know.

I know this attitude of mine is very different from traditional UNIX
mentality but I hope you can see the benefits of only enforcing policy
from the desktop session.

Thanks for reading this.

Cheers,
David