Light sensor

[Jeff Andros]

On 11/30/06, Richard Franks <richard.franks at drdc-rddc.gc.ca> wrote:
>
> On Thu, 2006-11-30 at 13:47 -0700, Jeff Andros wrote:
>
>
> > 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)
>
> As a matter of personal preference, I'd prefer to avoid sticking
> abstracted concepts into /dev - start with /dev/available and you end up
> with 100's of entries
> including
> /dev/probability-of-the-user-feeling-like-a-grilled-cheese-sandwich -- it's
> not as scalable.


I hadn't thought about this, I figured since most of the sources should be
other devices, we wouldn't get filled up, simply put each device would
provide a pointer to a method extending the standard character driver from
within the device driver, and we'd include this functionality within the
kernel, but you're right, if we have to implement more than just one virtual
device, we'd better find another place to stick this functionality

A 'plugin' is a high-level user concept - the transforms I described
> also work as 'plugins', but I think we're talking about the same thing..
> so written down in transforms, what you describe would be:
>
> [multiple sinks] => .... -> (user availability)
>
> And whether or not the phone rings when a call comes in:
>
> Sinks:
> (caller)
> (user availability)
>
> Process:
> compares scores
>
> Sources:
> (ring/silent notification/vibrate/ignore)
>
>
> The difference in implementation is moving away from a rigid rule-based
> system (there was an article posted a day or so ago describing these) as
> with rules, each component decides too much upon its own, and it has no
> way to deal with rule-conflicts as each application is left to construct
> its own closed-decision-chain. In this system, each application doesn't
> have to waste system resources (read:battery life) reinventing the
> wheel.


so you're suggesting that each application have access to the raw feeds from
each notification device?  there are definite  advantages, and you'd have a
more flexible system. I'm just thinking of a more asymetric system where
each device notifies /dev/available device when something changes... this
would also put us into kernel mode for computing (I'm not sure if this is
good or bad... or both).  raw access to the sensor feeds would be excellent
because I could differentiate between laying on the desk in the light in the
library (I'm probably across the room... ring louder, don't vibrate) or in
my pocket in my car.  the problem with doing it this way, is you'd need some
way to notify each application of all the sensors available at runtime, or
you re-compile each availability sensitive app for every combination of
sensors (having that many versions of software is sure to turn off Sean's
dad) there's definately more to think about on this one

>From your example, say 'availability' was a datasource between 0-255,
> with user-defined cutoffs (e.g. 250 = anyone but smelly john can call
> me) then the application still has the freedom to override the
> system-consensus, but such deviations are explicit.
>
> Richard
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
>



-- 
--Jeff
What DO you call whitewater when you live in the desert?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20061130/0d329224/attachment.htm