HAL: camera

[Sean Middleditch]

On Thu, 2004-01-15 at 16:06, Robert Love wrote:

> Now, I am not so sure I agree.  One reason it _is_ nice is that apps
> that use HAL (like g-v-m) don't really tend to have state, because HAL
> handles everything.  g-v-m, for example, could be modeled as a FSM
> without any storage (is that called a finite automaton?), so there
> really is no reason g-v-m couldn't be invoked on the command line, do
> its thing, then die.  But I also think that the majority of HAL-using
> apps are going to end up being daemons anyhow, and we still need the
> D-BUS layer and libhal, so having a rich configuration system might not
> be unneeded complexity.  It is always something that can be added to the
> policy-side of hardware management, anyhow.

Right.  I didn't think for a moment to get rid of these things.  Just
for, certain cases, it may be more efficient both computationally and so
far as developing the application for it to be launched in receipt of an
event vs. constantly running and waiting for it.

I don't, of course, have any kind of example to show what the specific
gains would be in the case of, say, gnome-volume-manager, and personally
I'm a bit leery of rewriting an app just for the sake of "thinking" it
might run better, especially if there's no real problem.

> 
> However, I think D-BUS is going to add activations (no?) which could
> make this moot anyhow.

Ah, yes, that would indeed.  No reason to sovle the problem twice,
then.  ;-)

> 
> 	Robert Love
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.