Rules based policy engine
sears at cs.berkeley.edu
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
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 gmail.com>:
>> 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
> Openmoko community mailing list
> community at lists.openmoko.org
More information about the community