[ohm] OHM vs. PPM
Kimmo Hämäläinen
kimmo.hamalainen at nokia.com
Mon May 5 08:26:07 PDT 2008
On Mon, 2008-05-05 at 17:14 +0200, ext Marcel Holtmann wrote:
> 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.
BR; Kimmo
>
> Regards
>
> Marcel
>
>
More information about the Ohm-devel
mailing list