Rules based policy engine

[Guillaume Chereau]

This is one of the thing I am planning to add in the framework (FSO
project), although for the moment we don't focus on it too much.

I agree with Alexey as well, the danger is to create something so
configurable, that at the end your setting become a python script.

My idea for the moment is like this :
You can define a set of condition to specify the profile. For example :
if at my girl friend house, profile = "Paranoid"

Then you the application configurations can depend on the profile. e.g :
If profile is "Paranoid", girl_friend_number_2.block_calls = True

This way, the profile is the link between the conditions set and the
actions set. The number of profiles is not supposed to be too large.

It is more restrictive that Russel idea, because you can't say :
if time = 600, then play alarm.

The only way to do so would be :
if time = 600, then profile = "RunAlarm"
if profile is "RunAlarm", then alarm.run = True

Which is not really useful, you don't want to create one profile for
every events combination you can think of.

I can see several cases where this way of doing is not the best, but I
still think it is the most suitable for most practical cases.

-charlie

On Thu, 2008-07-17 at 17:46 -0700, Russell Sears wrote:
> 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.
> > 
> > 
> 
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.openmoko.org/pipermail/community/attachments/20080718/f678e690/attachment.pgp