<br><br><div><span class="gmail_quote">On 11/30/06, <b class="gmail_sendername">Richard Franks</b> <<a href="mailto:richard.franks@drdc-rddc.gc.ca" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
richard.franks@drdc-rddc.gc.ca</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu, 2006-11-30 at 11:51 -0700, Jeff Andros wrote:<br>><br>> It almost sounds like we should make a plugin framework for<br>> availability detection, with plugins for the light sensor, PIM<br>> calendar, microphone (can we set an interrupt if the ADC receives a
<br>> level greater than X?) and so on and so forth as people figure out<br>> other ways to detect it<br><br>I'd prefer something a little more generic.. how about considering it as<br>a network of transforms? Where each transform is a simple plugin, of the
<br>sink/process/source variety?<br><br>For example, the physical hardware would be a series of available<br>datasources, I'll start with the simplest:<br><br>(microphone voltage sample)<br><br>So a voice recording utility could subscribe to the (microphone voltage
<br>sample) for a duration of its choosing - and it now has a recording.<br><br>Except, you may want to filter out snaps and crackles.. so you load the<br>filtering transform:<br><br>(microphone voltage sample) -> (snap and crackle filter) -> (processed
<br>microphone sample)<br><br>The application above can now subscribe to the (processed microphone<br>sample) instead of the raw voltage sample, if it chooses.<br><br>Now say we want to know what the average volume is over one second. We
<br>load another transform (average amplitude), and pass it the parameter<br>duration:1000ms:<br><br>(microphone voltage sample) -> (average amplitude) -> (average<br>amplitude:1000ms)<br><br>You could have another application which wants to know what the average
<br>is over two seconds.. so now the (average amplitude) transform is<br>servicing two datasources:<br>(average amplitude)<br> -> (average amplitude:1000ms)<br> -> (average amplitude:2000ms)<br><br>So in the end, the (activity-monitoring) transform would be built from:
<br><br>(microphone voltage sample) -> (average amplitude) -> (input1)<br>(light sensor value) -> (average amplitude) -> (input2)<br>(time of day) -> (schedule comparison) -> (input3)<br>(time since last user activity) -> (input4)
<br>etc etc..<br><br>But in the end, you have system-wide consensus with regards whether the<br>user is active, and each application which cares just has to subscribe<br>to the (activity-monitoring) data-source to find out.
<br><br>There's a *lot* of implementation details I've skipped over, but in<br>essence I think such a system gives the power to grant conceptual<br>abstraction and system-wide consistency, with simplified and less<br>redundant development.
<br><br>Er, in other words, I can't think of another way in which we could avoid<br>the scenario whereby you have two similar applications which come to<br>separate conclusions based upon the same inputs - one concludes the user
<br>is awake, the other concludes that the user is not.<br><br>Richard<br><br>_______________________________________________<br>OpenMoko community mailing list<br><a href="mailto:community@lists.openmoko.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
community@lists.openmoko.org
</a><br><a href="http://lists.openmoko.org/cgi-bin/mailman/listinfo/community" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.openmoko.org/cgi-bin/mailman/listinfo/community</a><br></blockquote>
</div><br>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)<br clear="all">
<br>-- <br>--Jeff<br>What DO you call whitewater when you live in the desert?