>> 1) How would you put that >> in an engine? Where does all the relevant info come from? >> 2) Then build aan interface to allow an end-user to create such rules. >> 3) And finally do something trivial with dbus, >> commandline (or even XML...) to play the appropriate ringtone. and show >> an Pickup/Cancel pair of buttons. > > there was some talk about this back in january or so... it got even more > involved than that: if the addressbook says I'm supposed to be sleeping, > but > the lights are on (maybe later we'll have an ambient light sensor) there's > lots of noise, the GPS shows I'm at a club, and the accelerometers detect > movement (those are going to be so cool) I'm probably not sleeping, go > ahead and ring (is it too tacky to list attendees for "sleeping" maybe you > don't want it to ring, but anyways)
Fun, I'll dig in the archives :) > the talk kind of centered around a nodeset somewhere in the filesystem, but > from what I've seen on dbus that might be a better solution. basically, > you > create a group of modules, each of which is queried for a result... then > each contact is matched against a set of rules based on the set of results. A module / rule hierarchy. Would that fit the exception-on-exception kind of rules we've been mentioning? I guess it could/ > on call importance, you can also list call frequency for the contact (I.E. > if john calls me 3 times in 5 minutes, it's probably something important... > ring on the third attempt) oh, greylisting :) _______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
