[ohm] OHM vs. PPM

[Marcel Holtmann]

Hi Kimmo,

> > > > >  > For the OHM vs GNOME Power Manager, I'd rather let Richard explain
> > > > >  > since he wrote those two, certainly with different designs in mind.
> > > > >
> > > > >  Right, the initial approach for OHM was to be system level because it
> > > > >  should also handle multiple session issues. And I don't see how this can
> > > > >  work if OHM itself would be part of a desktop session. I just wonder where
> > > > >  the request making OHM per session actually came from...
> > > > 
> > > > I wrote OHM in a few days to show a simple project that could be used
> > > > system wide for the nokia tablets or the OLPC laptop - it just wasn't
> > > > designed to be per-session like you guys are suggesting. Being blunt,
> > > > the session use-case is already being served by kpowersave,
> > > > gnome-power-manager and guidance-power-manager, so I really see OHM
> > > > fitting in system wide for the niche cases, not session wide for a
> > > > generic desktop.
> > > > 
> > > > For the embedded or server user case, a session wide daemon just
> > > > doesn't make sense IMO.
> > > 
> > > It'd be best to have only one OHM daemon running in the system, at least
> > > for the RAM-constrained embedded case. Session-specific policies could
> > > be implemented through configuration, interpreted policy language, or
> > > plugins. It should not be difficult to find out whose home directories
> > > to scan, and when, for session-specific configuration.
> > 
> > while it is possible to scan home directories, but that is a big no-no.
> > A system daemon interaction with the user should not be based on files
> > in users home directory. Use D-Bus if you wanna retrieve user input or
> > have the user set policies. Otherwise you have a big layer violation in
> > your design and not to talk about the potential security impact of doing
> > this.
> 
> I'm not convinced that it's not possible to implement with a single
> daemon. D-Bus is a new technology and these kind of layer problems have
> been solved before. I'm just worried about the number of daemons. Every
> solution to a problem seems to require at least two D-Bus services
> nowadays, and all these services take resources. D-Bus messaging and
> related startup of daemons is not so simple to get right either. D-Bus
> also adds unnecessary overhead to all these solutions.

just to make my point clear. I think that it has to be a single system
daemon. Having multiple session daemons make no sense. Especially since
you wanna do some task even before any user is logged in or even without
having any user logged into the system at all.

My point was against scanning users home directories. That is simply the
wrong way of trying to solve it.

It should be client/server architectures in most cases. And the server
should have good defaults to do its job without any client available. If
the client is running all the time or if the client only sets certain
policies is a different story. That highly depends on your target
system.

I think that having system related defaults and then have applications
overwrite or enhance them is the right way. So if your application wants
the backlight on all the time, then it can tell so. This doesn't add any
extra component to the system since your application was there in the
first place.

Regards

Marcel