Rules based policy engine

[Ryan Meador]

Russell Sears <sears at ...> writes:

> 
> I fell out of this discussion for a while, but I'd much rather see a 
> very simple C API that delivers events from DBUS with bindings for 
> python / your favorite language.  The event system and programming model 
> (rule based, prolog, python, ...) should be completely separate modules. 
>   That way, you don't need to design your application around being able 
> to  receive external events.
> 
> Also, if we couple the event system to the programming language, then 
> all other languages become second class citizens.  That would suck.
> 
> I'd like to clarify my original post.  (Also, I still haven't looked at 
> D-BUS, it might already do most/all of this stuff.)
> 
> These two lines are meant to be function invocations, perhaps in C or in 
> python:
> 
> register_event_handler("/phone/incoming_call = true",
>                          mute_music_callback)
> 
> register_event_handler("/clock/time = 600",
> 		       play_alarm_callback,
>                          "loud_buzzer.ogg")
> 
> register_event_handler() should be a C function that takes three arguments:
> 
> 1: A char* containing a query written in a small domain specific 
> language.  I don't think we need support for more than:
> 
>   a)  =, <, >, ...
>   b)  Conjunction + disjunction; && and ||, which means "all of" or "one
>       of" these rules match
> 
> The following two would be nice, but might make things harder to implement:
> 
>   a)  Parenthesis for grouping
>   b)  Negation
> 
> xpath is a well-known language, and is close, though I don't know how 
> well existing implementations deal with events (ie: third parties making 
> changes to the underlying xml document).  Also, I think xpath is 
> probably too complicated.
> 
> 2: A function pointer of type void (fcn*)(void *)
> 
> This gets invoked when the evaluation of the query changes from false to 
> true.
> 
> 3) A void *
> 
> The application program controls what goes in the void*.
> 
> Applications should be able to build all sorts of things with these 
> primitives, including new domain specific languages.
> 
> It would be good to make sure that it's easy to have prolog or some 
> other rule based system autogenerate and interface to the small domain 
> specific language.  I think the way it would work is prolog would use 
> some event handlers to maintain a table of facts that the DSL would then 
> use as its base database.
> 
> Also, datalog would be a much better choice than prolog.  The outcome of 
> prolog programs depends on the order in which rules are defined.  This 
> isn't true for datalog, which has cleaner semantics.  The two languages 
> have nearly identical syntax.
> 
> -Rusty
> 

I think I may have been unclear... I was suggesting Prolog for the "small
domain-specific language" you're talking about.  Nowadays, pretty much no one
writes entire applications in Prolog, they just use it within another language
to implement a rules engine.  I know nothing of Datalog, but I'll take your word
for it that it's better -- if it's similar to Prolog, I'm sure it will get the
job done.  A logic-based language has all the primitives you mentioned (and
indeed all of first-order logic).  Learning Prolog well enough to use it for
this purpose would probably take all of half an hour and can be accomplished by
reading the wikipedia page (with examples).  It seems to be a ready-made
solution to exactly this problem with a minimal startup time.  As it is only the
"domain-specific language", the application it resides in (some kind of
dbus-connected event server?) can be in any language that we can get a prolog
interpreter for, which basically means any of the common ones like C++ or Java
(and probably python).  I think I may have unintentionally confused a few people
by suggesting Prolog as the language when it itself can be compiled to a binary.
 If you really wanted to, you could use Prolog for the whole app, but I just
suggest it for the rule interpreter itself.