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 Chris Wright wrote: > 2008/7/20 Ryan Meador <[EMAIL PROTECTED]>: >> 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@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community