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 _______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
