Rules based policy engine
matt.joyce at gmail.com
Tue Jul 22 04:33:49 CEST 2008
I'd like to see a diagram showing how you envisage this fitting together.
Somethings like :
App1<=>D<=>[event handler, current states]<=>[rules
I'm not clear on the existing role or use of DBUS, are existing apps
(gsmd, gps, mplayer, contacts, clock, diary, etc) already DBUS aware,
do they publish their events, or states queried?
On Tue, Jul 22, 2008 at 4:27 AM, Russell Sears <sears at cs.berkeley.edu> wrote:
> 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 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
> > want.
More information about the community