G-P-M on the wrong track?!

[Timo Hoenig]

Hi,

On Mon, 2005-10-17 at 11:58 -0400, John (J5) Palmieri wrote:
 
> This makes sense.  After rethinking my earlier assessment there are a
> couple of reasons to have a separate daemon.  First is security, with a
> separate daemon we can define who can talk to it a lot easier though I
> am not convinced what HAL does right now is of any risk.  Second is your
> point about non-loggedin behavior.  There is no way for the HAL addons
> to set policy so even if we kept the functionality in HAL a client
> daemon would still have to be run as root.
> 
> It shouldn't be that hard to extract the functional bits from g-p-m and
> put them into a daemon.  I don't know if powersave is the best place or
> not.  It looks good but I am concerned about powersave trying to do too
> much but then again I only took a five minute glance at the code.
> 
> After reassessing, HAL should definitely remain the canonical source for
> all information on management devices with the daemon being used for
> system wide default policy and interface for overriding that policy by
> logged in users (or scripts, or whatever).  In other words as stated
> elsewhere in this thread we need a constant D-Bus interface and a daemon
> that implements it.  It shouldn't be hard in the short term to make g-p-
> m's functional bit into a daemon and then in the long term perhaps merge
> powersave and the daemon part of g-p-m.  I think the design goals are
> all the same and this is just implementation details.  
> 
> How far along is powersave in using HAL as the source of device info?
> Merging the bits that HAL doesn't do would be good.  

I'm sure that Danny and Holger will be happy to go into detail about
this.

> 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.

Being of a very desktop-multicultural type of guy I'm really seeing this
as they way to go.

It is very much the same situation as we're facing with NM at the
moment.  We got one proper daemon/client implementation which "just"
needs another client to be implemented to satisfy others, too.   

See you,

   Timo