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