On 11/30/06, Richard Franks <[EMAIL PROTECTED]> 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@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
-- --Jeff What DO you call whitewater when you live in the desert?
_______________________________________________ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
