Light sensor

Richard Franks richard.franks at drdc-rddc.gc.ca
Thu Nov 30 22:31:20 CET 2006


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.

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.

>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




More information about the community mailing list