Rules based policy engine
matt joyce
matt.joyce at gmail.com
Fri Jul 18 12:30:06 CEST 2008
Guillaume Chereau wrote:
> 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
>
>
Profiles, recipes, rulesets; I think we all talking about the same
thing, behaviours.
It boils down to detecting a set of conditions and instructing the phone
to behaviour in a certain way.
Profiles are an excellent way of describing a group of common phone
settings. (settings the call handling services already respect)
People are familiar with the concept, they could be described by setting
a phone using normal method and saving them.
Perhaps if there was a default profile, and we only store differences,
the delta, in other profiles, we could have cumulative profiles.
That might help with the tedium of setting up every permutation and keep
the number of profile down.
Profiles are really just a bunch of SET actions.
I still see the need for an event broker of sorts, something that will
detect conditions and trigger actions.
Perhaps the profile switcher (as some else mentioned) could be enhanced
for that purpose.
An alarm might just be a custom action, just another action. 'Run a
shell command' might be the only action we need.
Another poster mentioned interacting with his MythTV, one approach might
be to configure the MythTV to run web server with some cgi.
The phone would just use http to instigate commands. wget?
If we had profiles and an event broker, all we need next is some
standard way to describe the set of conditions.
I'm no hardcore coder, but it seem well within the realms of possibilities.
I still favour a scriptable solution, even is it wrapped in UI and
machine generated.
Regards
Matt
More information about the community
mailing list