[patch] pmu patch

[David Zeuthen]

On Thu, 2005-02-03 at 14:27 +0100, Pozsar Balazs wrote:
> I think it would better to let hal compute remaining time. If it doesn't 
> do so, then every applet out there has to implement the same thing. I 
> think it would be nicer to only have it implemented in ONE place, and in 
> this case, it is hal.
> 

What if someone comes up with a much nicer algorithm for computing
remaining time? What if the algorithm requires storing stuff
on disk in a persistent manner? No, I don't see *any* need to let
hal do that work - that's just a violation of the layering.

If you want it in a single place go write libhal-powermgmt; I don't
mind storing that in CVS next to libhal-storage (where libhal-storage
somewhat serves the purpose for drives and volumes.). There's no point
in putting unnecessary code in a system-level daemon like hald.

> > Yeah, I don't really know where we should put it :-). One might argue
> > it's a bit cracktastic to let hal expose such information :-) - dunno;
> > I'm worried about the bandwidth for exporting a lot of device objects
> > with changing properties..
> 
> If there are bw problems, then those should be solved, and the solution 
> is not filtering objects...
> 

Uhm, but that's how D-BUS works - the system message bus receives all
changes and filters accordingly, only sending changes out to processes
that are interested. So, worst case is there that there is lots of
traffic between the hald and dbus-daemon-1 processes. 

My point was really this: what is the use of relaying temperate and
fan rpm information? What policy agent is going to use it? Why is it
useful?

Cheers,
David


_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal