Light sensor

[Richard Franks]

On Thu, 2006-11-30 at 11:51 -0700, Jeff Andros wrote:
>
> It almost sounds like we should make a plugin framework for
> availability detection, with plugins for the light sensor, PIM
> calendar, microphone (can we set an interrupt if the ADC receives a
> level greater than X?) and so on and so forth as people figure out
> other ways to detect it

I'd prefer something a little more generic.. how about considering it as
a network of transforms? Where each transform is a simple plugin, of the
sink/process/source variety?

For example, the physical hardware would be a series of available
datasources, I'll start with the simplest:

(microphone voltage sample)

So a voice recording utility could subscribe to the (microphone voltage
sample) for a duration of its choosing - and it now has a recording.

Except, you may want to filter out snaps and crackles.. so you load the
filtering transform:

(microphone voltage sample) -> (snap and crackle filter) -> (processed
microphone sample)

The application above can now subscribe to the (processed microphone
sample) instead of the raw voltage sample, if it chooses.

Now say we want to know what the average volume is over one second. We
load another transform (average amplitude), and pass it the parameter
duration:1000ms:

(microphone voltage sample) ->  (average amplitude) -> (average
amplitude:1000ms)

You could have another application which wants to know what the average
is over two seconds.. so now the (average amplitude) transform is
servicing two datasources:
(average amplitude)
  -> (average amplitude:1000ms)
  -> (average amplitude:2000ms)

So in the end, the (activity-monitoring) transform would be built from:

(microphone voltage sample) -> (average amplitude) -> (input1)
(light sensor value) -> (average amplitude) -> (input2)
(time of day) -> (schedule comparison) -> (input3)
(time since last user activity) -> (input4)
etc etc..

But in the end, you have system-wide consensus with regards whether the
user is active, and each application which cares just has to subscribe
to the (activity-monitoring) data-source to find out.

There's a *lot* of implementation details I've skipped over, but in
essence I think such a system gives the power to grant conceptual
abstraction and system-wide consistency, with simplified and less
redundant development.

Er, in other words, I can't think of another way in which we could avoid
the scenario whereby you have two similar applications which come to
separate conclusions based upon the same inputs - one concludes the user
is awake, the other concludes that the user is not.

Richard