On 11/30/06, Richard Franks <[EMAIL PROTECTED]> wrote:
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
ok, I was thinking more like /dev/random pulls seeds from all the devices registered with it, or the way that mythtv detects commercials based on plugins, create a virtual device that returns a read of 0-255 based on the probability that you're available... as each device(light sensor, etc) is added, it would register with /dev/available as a detection device, and provide a function to return another byte value of what it thinks the user's doing. the available device would perform some kind of heuristic on this. then when a call comes in, the receiver daemon checks with /dev/available, then uses the value returned to decide what to do. different events could have different values (e.g. the girlfriend calls, it'll ring if the value is greater than 3 (basically not dead... probably from a VOC sensor) but if the bill collectors call, the value better be 250+ or I'm not getting bothered) -- --Jeff What DO you call whitewater when you live in the desert?
_______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
