Rules based policy engine

Russell Sears sears at
Mon Jul 21 20:27:11 CEST 2008

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 

register_event_handler("/phone/incoming_call = true",

register_event_handler("/clock/time = 600",

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 

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.


Chris Wright wrote:
> 2008/7/20 Ryan Meador <ryan.d.meador at>:
>> I think it's important that we use an existing general-purpose platform such as
>> Prolog (at least, it's about as general purpose as logic programming gets...).
> I would favor Rhino.DSL, simply because I know it integrates well with
> a language with dbus bindings. And because it can probably result in
> very readable syntax. And it's based on Boo, which is very nearly
> Python, and thus more accessible to most programmers than Prolog.
> Does dbus allow you to specify your priority when listening to an
> event, and to prevent it from being published to other listeners? If
> not, then the first step is to separate the relevant dbus events and
> come up with an application that merely translates unconditionally
> between the two. And that allows you to insert any rules engine you
> want.
> _______________________________________________
> Openmoko community mailing list
> community at

More information about the community mailing list