Rules based policy engine
alexey at feldgendler.ru
Fri Jul 18 01:59:10 CEST 2008
On Fri, 18 Jul 2008 01:01:08 +0200, matt joyce <matt.joyce at gmail.com>
> 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
More information about the community