Rules based policy engine

[Russell Sears]

I agree with most of what Alexey said, but I would love to see some sort 
of easy to use scripting / gui environment.  I think the FSO stuff is 
working on some sort of d-bus event notification system.  Presumably 
there's a set of python / c libraries that know how to talk to dbus, and 
provide a simple wrapper on top of everything.  (I haven't looked at FSO 
or DBUS yet... ;)

I wonder if this is a job for some simple query language like a subset 
of xpath or xquery.  It could re-evaluate an expression each time a dbus 
event could change the expression's results.  It would also simplify 
writing things like "pause my music when the phone rings", alarm clocks, 
etc:

register_event_handler("/phone/incoming_call = true",
                        mute_music_callback)

register_event_handler("/clock/time = 600",
		       play_alarm_callback,
                        "loud_buzzer.ogg")

and so on...

These event handlers could live in a python script (or, better) inside a 
simple GUI app.

I think most people that own one of these things knows how to program. 
Improving their productivity a bit should be a big win when the consumer 
version of the phone ships...

-Rusty

Alexey Feldgendler wrote:
> On Fri, 18 Jul 2008 01:01:08 +0200, matt joyce <matt.joyce at gmail.com>  
> wrote:
> 
>>    If it can be reliably established that my physical location is one of
>> my favourite restaurants please switch my phone to vibrate, unless my
>> babysitter calls.
>>    If I miss a call or I receive an SMS from from any of my work
>> contacts during work hours, and I don't respond, please remind me.
>>    If it's not during work hours, do not take any calls from contacts
>> exclusively in my work contacts.
>>    If my home wifi is available and my battery is not too low, don't use
>> GPRS for data.
>>    If it a WEEKDAY and 06:00, turn on, play alarm, connect to WIFI and
>> start getting email and rss.
>>    At 21:00 on weekdays, switch to standby.
>>    If my battery is low and I'm at home, remind me to charge.
>>    If I'm at home disable my auto-lock.
> 
> The problem with this is that one needs to think like a programmer to  
> describe your “ideal phone” as a set of rules like these. Not only does  
> one have to think analytically and dissect their concept into orthogonal,  
> machine-checkable rules, but from your examples it's also clear that for  
> such a wide range of possibilities a whole *language* with *expressions*  
> (at least boolean) is necessary.
> 
> Moreover, if one *is* a programmer, and has learned the rule expression  
> language, there will be bugs in the rulesets, like overlooked priorities  
> or excessively permissive conditions, and you'll spend some time debugging  
> it, probably missing a few important calls and alarms now and then in the  
> process. Next step would be debugging tools for rulesets, allowing to  
> simulate times of day, different conditions and incoming events to test  
> the rules. Next, backup and revision control for rulesets. This is where  
> madness lies: you have to modify and debug a program in a declarative  
> logic language when you start dating someone because it breaks all your  
> carefully polished ruleset. Sounds like a topic for XKCD. Randall, are you  
> by any chance reading this?
> 
> I understand that you must be thinking, “This phone is fully programmable,  
> so I can make it do whatever I want”. True. Now, by defining sets of  
> possible conditions and actions and letting the user make rules out of  
> these, you're basically saying: “Here is a computer. You can program it to  
> do whatever you want”. While this might be usable for someone who is a  
> programmer (and who's willing to be a programmer when they deal with their  
> cell phone), it's not a killer application. It's an absence of  
> application; it's rather an interpreter for a programming language in  
> which a user can write themself a killer application.
> 
> The key to making a phone do what you, I or someone else wants is rather  
> in analyzing our requirements and figuring out what parts are constant and  
> what are changing. Of course, all people want different things, and the  
> same person wants different things at different times. But the number of  
> dimensions in the space of all reasonable people's demands is still much  
> less than that of the space of all possible rulesets. Only a small subset  
> of all possible rules, let alone rulesets, makes any sense at all, while  
> the vast majority is nonsensical, such as “When WiFi is available and  
> John's phone is nearby, mute all calls”, or “If I have unread SMS on  
> Thursday, prefer GPRS”. Analyzing and isolating the axes of user demands  
> is much harder than developing a ruleset-driven engine, but at least it  
> has a chance of becoming usable.
> 
>