Rules based policy engine

[Alexey Feldgendler]

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.


-- 
Alexey Feldgendler <alexey at feldgendler.ru>
[ICQ: 115226275] http://feldgendler.livejournal.com