G-P-M on the wrong track?!

[John (J5) Palmieri]

On Mon, 2005-10-17 at 19:24 +0200, Matthias Grimm wrote:
> On Mon, 17 Oct 2005 11:58:35 -0400
> "John (J5) Palmieri" <johnp at redhat.com> wrote:
> 
> > This is all stuff that is just better if we all collaborate on one
> > solution.  The client are different but on the backend it seems
> > worthwhile.  Powersave should really be moved to fd.o if we do go down
> > that road but that is a different issue.
> 
> IMHO this must be the main aim: To get a generic powermanagement backend.

Don't use the word generic.  What we need is a solution that is specific
to power management.  Sorry nit-picky, but whenever someone tries to
come up with a "generic" solution things end up bloated and
unfocused.   
  
> 
> We won't have one generic power management daemon in the first step. The
> differences between architectures are to big for this approach but we could
> generalize the interface to the desktop.
> 
> So the fist steps will be:
>   - define a power management infrastructure in HAL which a power
>     management daemon has to fill

HAL should do this directly.

>   - define a power configuration setup in HAL which the PM daemon
>     should take into account. Options set in HAL overwrite default
>     options of the PM daemon.

Are options set in HAL?  I don't think this is wise.  I'm more apt to go
with whatever powersave does for configuration and build on that
(assuming power save is the way to go).  Initially I would just say
extract the code needed for the daemon and get things working the way
they do now while defining a common D-Bus interface.

>   - define a set of and dbus signal and methods for commands a user
>     might want send to a PM daemon.

Just mirror what G-P-M does now and look where it intersects powersave.

For the rest of your mail, let's take it one step at a time.  That first
step would be getting the right mix of HAL and daemon. 

-- 
John (J5) Palmieri <johnp at redhat.com>