Re: Rules based policy engine
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 took some time to read the wikipedia pages for bother Prolog [1] and Datalog [2], both interesting. I found some Prolog libs for Python but not for Datalog, but I found source code for Datalog - A deductive database system for memory constrained devices. [3], a quick look suggests it written in C. Might be interesting. I think it's important to keep jotting down potential uses for this system, I think I may whip up a wiki page at some point. With inference in mind, a small gui app which simply asks Where are we now ? The user enters Work, or Home, etc. The app informs the rule system about all the GMS towers it can detect, and WIFI networks and the tag the user entered. A pretty simple way of training the system, I think. How about a location based home pages on the browser or rss. I'm at the station (because the rule system infers that I am), show me the traffic news rss. At work, show me my Nagios status page. At home my weather station page. (is that sad?) Anywhere else, google please. I'm pretty sure GSM locations would work for this sort of thing. Comments welcomed. Regards Matt [1] http://en.wikipedia.org/wiki/Prolog [2] http://en.wikipedia.org/wiki/Datalog [3] http://www.ccs.neu.edu/home/ramsdell/tools/datalog/index.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ruleby was: Rules based policy engine
Scott wrote: I just found this inference engine. http://ruleby.org/wiki/Ruleby I working on a Rails project think Ruby is a great language to work with. And Ruby is pretty small.. A bit too many layers there for my taste. :) A domain specific rules language implemented in ruby embedded in c? The ruby layer does not seem to be thin enough to justify that. (ok, writing rules in ruby is kind cool. As would any other real language be. Like lightweights like lua or certain lisp-ish languages. Even javascript would not be bad.) Btw. I like the idea of a rules language. But why not something simple and stupid like for example SIEVE filters in cyrus imap. That's a hand full of yacc and lex magic and some stupid engine code. I mean, what we can match is pretty much defined by the fact that we match numbers and SMS. A hand full of logic expressions on pre defined attributes should be enough. My email filter is not smarter too, but email a lot more complicated. And it works well. If someone puts the effort in to something like Prolog or Ruleby i will not argue. But it seems a bit overkill to me. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ruleby was: Rules based policy engine
Tilman Baumann wrote: Scott wrote: I just found this inference engine. http://ruleby.org/wiki/Ruleby I working on a Rails project think Ruby is a great language to work with. And Ruby is pretty small.. A bit too many layers there for my taste. :) A domain specific rules language implemented in ruby embedded in c? The ruby layer does not seem to be thin enough to justify that. (ok, writing rules in ruby is kind cool. As would any other real language be. Like lightweights like lua or certain lisp-ish languages. Even javascript would not be bad.) Btw. I like the idea of a rules language. But why not something simple and stupid like for example SIEVE filters in cyrus imap. That's a hand full of yacc and lex magic and some stupid engine code. I mean, what we can match is pretty much defined by the fact that we match numbers and SMS. A hand full of logic expressions on pre defined attributes should be enough. My email filter is not smarter too, but email a lot more complicated. And it works well. If someone puts the effort in to something like Prolog or Ruleby i will not argue. But it seems a bit overkill to me. I agree with Rusty's idea (somewhere in this thread), if it's built as modules, the rules processing could be done by various efforts. Python, Ruby, Sieve, Prolog, Datalog, C; how fantastic that we have the chance (and choice) of any (all), including those we haven't thought of yet. Fertile times indeed! For some (me) the FR is a toy of sorts, something to explore. For others it's a tool, something to solve a problem with. I suspect it's partly an act of rebellion too. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Hi, I'm one of the GSoC students and work on the answering machine. I already use this concept in my project and it uses modules so it might be possible to extend it to fit your needs. It's implemented in vala so you can use all GLib functionality and more. As far as you can create vala bindings for it or you can use C and GObject. I just implemented 2 types of connecting rules yet: all of them or one of them. Also a complex type might be possible. my current rules are: -time ( depending on day of week and current time) -calendar ( depending on your entries in you calendar ) -GPS ( depending on a GPS position and a radius around this ) my current actions are: - run a custom command on startup and at the end - answer call: yes it is an answering machine - answer asterisk call: this should also be answered - send sms: send a user defined message to a caller Here you can find the class diagram [1]. it will be updated soon. Regards, Frederik [1]: http://v1187.ncsrv.de/classes.jpeg ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
On Wed, Jul 23, 2008 at 6:41 AM, Frederik Sdun [EMAIL PROTECTED] wrote: Hi, I'm one of the GSoC students and work on the answering machine. I already use this concept in my project and it uses modules so it might be possible to extend it to fit your needs. It's implemented in vala so you can use all GLib functionality and more. As far as you can create vala bindings for it or you can use C and GObject. I just implemented 2 types of connecting rules yet: all of them or one of them. Also a complex type might be possible. my current rules are: -time ( depending on day of week and current time) -calendar ( depending on your entries in you calendar ) -GPS ( depending on a GPS position and a radius around this ) my current actions are: - run a custom command on startup and at the end - answer call: yes it is an answering machine - answer asterisk call: this should also be answered - send sms: send a user defined message to a caller Here you can find the class diagram [1]. it will be updated soon. Regards, Frederik [1]: http://v1187.ncsrv.de/classes.jpeg Frederik, Can you explain how/where you define the rules? Also, how are you gathering event information? Thanks Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
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
Re: Rules based policy engine
Russell Sears [EMAIL PROTECTED] 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. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
I'd like to see a diagram showing how you envisage this fitting together. Somethings like : App1=D=[event handler, current states]=[rules engine]=[rules]=[rules gui] App2=B App3=U App4=S 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? Matt On Tue, Jul 22, 2008 at 4:27 AM, Russell Sears [EMAIL PROTECTED] 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 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
Re: Rules based policy engine
If GPS position is going to be a phone answering rule you would have to have the GPS sub system running all the time. It can't wake from sleep and acquire a position soon enough go be part of the decision. Not sure what that will do to battery life. Scot signature.asc Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Scott Derrick wrote: If GPS position is going to be a phone answering rule you would have to have the GPS sub system running all the time. It can't wake from sleep and acquire a position soon enough go be part of the decision. Not sure what that will do to battery life. Scot That's a valid point. However, if a GPS dependant rule cannot get a fix (because it's off) in a timely fashion, the rule fails. It may be possible to use GSM call towers to give a good enough location for these rules. Looking at this rule again : 'If it can be reliably established that my physical location is one of my favourite restaurants please switch my phone to vibrate, unless my babysitter calls.' 'reliably' is the operative word here, and I may consider GSM based location, reliable. If a profile switching approach is taken, we could switch to the vibrate with exceptions' profile and shutdown GPS. On the other hand, if always-on GPS is what's needed, then future models will have to address the power requirements. Or, perhaps a case mod for larger batteries is required. Presumably geo-mappers have this problem already. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Scott Derrick, 2008-07-20 06:45:44 -0600 : If GPS position is going to be a phone answering rule you would have to have the GPS sub system running all the time. It can't wake from sleep and acquire a position soon enough go be part of the decision. Not sure what that will do to battery life. You could approximate with the GSM cell identifiers. Roland. -- Roland Mas Et c'est tellement plus mignon de se faire traiter de con en chanson... -- in En chantant (Michel Sardou) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
It may be possible to use GSM call towers to give a good enough location for these rules. a gsm cell is usually much bigger than most restaurants -- and gps might not be available inhouse. btw: a rule that analyses calendar entries and depending of the character of the appointment disables ringing might be sensible. thus i only have to select the importance/category of the appointment and not to worry about forgetting to disable the phone. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
On Sun, July 20, 2008 3:28 pm, arne anka wrote: a gsm cell is usually much bigger than most restaurants -- and gps might not be available inhouse. True, but you can still use the GSM cell to determine that you are not in the restaurants, because you are in a different cell on the other side of town. The rule interpreter could check he GSM cell ID to determine if you might be near enough to a significant point before starting the GPS to determine your exact location. Alternatively, the user might decide that for most rules, the approximate location from the GSM cell is good enough. For example, my local cinema is in a fairly isolated spot out of town. If I am within a couple of miles of it, the chances are I will be going to the cinema shortly, or I have just left, so a rule switching the phone to silent mode if I am in the same GSM cell as the cinema would be good enough. -- David Pottage Error compiling committee.c To many arguments to function. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
I thought about it awhile and decided that you could have the GPS engine get a fix every 5 minutes or some user adjustable time frame and use the last known fix. 99% of the time it would probably be close enough. Scott matt joyce wrote: Scott Derrick wrote: If GPS position is going to be a phone answering rule you would have to have the GPS sub system running all the time. It can't wake from sleep and acquire a position soon enough go be part of the decision. Not sure what that will do to battery life. Scot That's a valid point. However, if a GPS dependant rule cannot get a fix (because it's off) in a timely fashion, the rule fails. -- The only security of all is in a free press. The force of public opinion cannot be resisted when permitted freely to be expressed. The agitation it produces must be submitted to. It is necessary, to keep the waters pure. Thomas Jefferson to Lafayette, 1823. ME 15:491 signature.asc Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Or, perhaps use GSM triangulation to trigger GSP fix acquisition. Scott Derrick wrote: I thought about it awhile and decided that you could have the GPS engine get a fix every 5 minutes or some user adjustable time frame and use the last known fix. 99% of the time it would probably be close enough. Scott matt joyce wrote: Scott Derrick wrote: If GPS position is going to be a phone answering rule you would have to have the GPS sub system running all the time. It can't wake from sleep and acquire a position soon enough go be part of the decision. Not sure what that will do to battery life. Scot That's a valid point. However, if a GPS dependant rule cannot get a fix (because it's off) in a timely fashion, the rule fails. ___ 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
Re: Rules based policy engine
arne anka wrote: It may be possible to use GSM call towers to give a good enough location for these rules. a gsm cell is usually much bigger than most restaurants -- and gps might not be available inhouse. btw: a rule that analyses calendar entries and depending of the character of the appointment disables ringing might be sensible. thus i only have to select the importance/category of the appointment and not to worry about forgetting to disable the phone. I agree. An extensible rules system which others developers can hook into would allow for this. The user might just select a phone profile (Do not disturb, except...) when they set her calendar appointment, and a rule can be generated, without the users becoming a programmer. A rule might exist, set profile whenever I meet with this contact, and the profile is auto-selected when the appointment is made. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Problem there is the rule based engine is trying to decide to answer the call, put it to voice mail, vibrate, ring loud, etc... Waiting 30-60 seconds for a cold start fix from the GPS is too long. Scott matt joyce wrote: Or, perhaps use GSM triangulation to trigger GSP fix acquisition. Scott Derrick wrote: I thought about it awhile and decided that you could have the GPS engine get a fix every 5 minutes or some user adjustable time frame and use the last known fix. 99% of the time it would probably be close enough. -- The only security of all is in a free press. The force of public opinion cannot be resisted when permitted freely to be expressed. The agitation it produces must be submitted to. It is necessary, to keep the waters pure. Thomas Jefferson to Lafayette, 1823. ME 15:491 signature.asc Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Sorry, I should have been clearer. What I meant was, if the rule engine/event broker has geo defendant rules, it could use GSM towers to ascertain if a GPS fix is required. This (or other checks, such as calendar, time) can happen prior to any voice/message events occurring, gsmd would just check for blocking rules (absence of) on event. Matt On Mon, Jul 21, 2008 at 7:51 AM, Scott Derrick [EMAIL PROTECTED] wrote: Problem there is the rule based engine is trying to decide to answer the call, put it to voice mail, vibrate, ring loud, etc... Waiting 30-60 seconds for a cold start fix from the GPS is too long. Scott matt joyce wrote: Or, perhaps use GSM triangulation to trigger GSP fix acquisition. Scott Derrick wrote: I thought about it awhile and decided that you could have the GPS engine get a fix every 5 minutes or some user adjustable time frame and use the last known fix. 99% of the time it would probably be close enough. -- The only security of all is in a free press. The force of public opinion cannot be resisted when permitted freely to be expressed. The agitation it produces must be submitted to. It is necessary, to keep the waters pure. Thomas Jefferson to Lafayette, 1823. ME 15:491 ___ 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
Re: Rules based policy engine
matt joyce [EMAIL PROTECTED] writes: Ryan, what approach have your efforts taken already? Any interesting insights to the problem? Matt My efforts as far as applying my inference engine to the OpenMoko platform basically consist of a few ideas rattling around in my head -- nothing concrete. I'm not a professional at this stuff, just an enthusiastic amateur trying to follow in the footsteps of some of the very interesting early AI research projects (most inference-based approaches to AI died out in the 80's, but a few are still around). To that end, most of my work has been focused on things not directly useful to a phone platform. 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...). This saves us from reinventing the wheel and also prevents us from thinking ourselves into a corner -- a general purpose system will likely be much more extensible and flexible for powerusers (and with this device, who isn't?) than something we dream up. Taking an inference-based approach to setting up the rules in the phone could allow us to create rules that are more abstract than most of the examples I've seen on this list. Instead of telling it don't use the ringer when I'm at the office, it could be don't use the ringer when I'm doing work. Work would be defined by other rules, such as your proximity to the office, whether or not you've scheduled an appointment in the calendar with contacts from work (think lunch meeting), and if you have a deadline that isn't marked as complete and it's only an hour away (you're probably workign furiously to meet it). That's just an example I created just now, and not particularly good -- good examples are hard to think of, but that's largely because the possibilities are endless. As one other person on the mailing list noted, the possible configurations of the rules engine that are nonsensical outnumber the meaningful ones by millions to one :) That babbling probably wasn't very helpful to anyone, but maybe it will at least build enthusiasm. I think the gist of it was mostly this: make it more flexible than it needs to be, and also make the rules capable of building on top of each other to create more complex conditions. Just my $0.02 :) Ryan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Am So 20. Juli 2008 schrieb Scott Derrick: Problem there is the rule based engine is trying to decide to answer the call, put it to voice mail, vibrate, ring loud, etc... Waiting 30-60 seconds for a cold start fix from the GPS is too long. But you can listen to mic to determine on ambient noise - just a few seconds maybe, or even after first gentle ringtone, and then adjust ringtone volume accordingly (pat. pend. jOERG ;) Also you can check the *echo* of the ringtone to decide whether you're in a silent room, in a pocket, under open sky... (pat. pend. jOERG ;) /j signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
On Mon, Jul 21, 2008 at 11:08 AM, Ryan Meador [EMAIL PROTECTED] wrote: matt joyce [EMAIL PROTECTED] writes: Ryan, what approach have your efforts taken already? Any interesting insights to the problem? Matt My efforts as far as applying my inference engine to the OpenMoko platform basically consist of a few ideas rattling around in my head -- nothing concrete. I'm not a professional at this stuff, just an enthusiastic amateur trying to follow in the footsteps of some of the very interesting early AI research projects (most inference-based approaches to AI died out in the 80's, but a few are still around). To that end, most of my work has been focused on things not directly useful to a phone platform. 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...). This saves us from reinventing the wheel and also prevents us from thinking ourselves into a corner -- a general purpose system will likely be much more extensible and flexible for powerusers (and with this device, who isn't?) than something we dream up. Taking an inference-based approach to setting up the rules in the phone could allow us to create rules that are more abstract than most of the examples I've seen on this list. Instead of telling it don't use the ringer when I'm at the office, it could be don't use the ringer when I'm doing work. Work would be defined by other rules, such as your proximity to the office, whether or not you've scheduled an appointment in the calendar with contacts from work (think lunch meeting), and if you have a deadline that isn't marked as complete and it's only an hour away (you're probably workign furiously to meet it). That's just an example I created just now, and not particularly good -- good examples are hard to think of, but that's largely because the possibilities are endless. As one other person on the mailing list noted, the possible configurations of the rules engine that are nonsensical outnumber the meaningful ones by millions to one :) That babbling probably wasn't very helpful to anyone, but maybe it will at least build enthusiasm. I think the gist of it was mostly this: make it more flexible than it needs to be, and also make the rules capable of building on top of each other to create more complex conditions. Just my $0.02 :) Ryan I find myself in a real quandary about this. On the one hand I want more flexibility, more inputs, more actions and such, because I feel creative uses will emerge from that. On the other hand my experience as an IT practitioner and technologist, instinctively tells me to keep it simple. I've spent most of my IT career trying to remove or prevent unnecessary complexity. Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
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
Re: Rules based policy engine
Steven Kurylo [EMAIL PROTECTED] writes: The problem with this is that one needs to think like a programmer to describe your ideal phone as a set of rules like these. Not only does one have to think analytically and dissect their concept into orthogonal, machine-checkable rules, but from your examples it's also clear that for such a wide range of possibilities a whole *language* with *expressions* (at least boolean) is necessary. I see it as something like sieve. Its a pretty full language for writing rules. I, as a programmer, I do almost anything I want. For the non-programmers there are various GUIs which allow you to do all the simple tasks with a couple clicks. In fact filter email is fairly similar: if these three things are true, do X. Then I have a stack of rules and it goes through them one at time until one is true. xpath might work. There are a few options, though I would try to stay away from writing our own if it can be helps. A plan old python class might be enough with function for each possible condition. I think what we're looking for here is Prolog (or something very similar). http://en.wikipedia.org/wiki/Prolog. I'd be very interested in contributing to (and using!) a rule-based system such as this. In addition to providing an inference-based rules engine written in first order predicate logic, it has the unique ability of adding rules with side effects (basically executing native code) when certain things happen... I think it would work nicely (it basically is for this purpose). I already had plans to create a rule-based system for the moko myself (an adaptation of a prolog-like inference system that I already have under construction). Due to the memory and processing constraints on the moko and the desire to reuse code whenever possible (which I agree with wholeheartedly), I think going with Prolog is probably a better choice than trying to finish my hacked-together and unproven inference engine. Now if only my Freerunner would arrive... dunno why it's been delayed by a week before shipping. Ryan Meador ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Ryan Meador wrote: Steven Kurylo [EMAIL PROTECTED] writes: The problem with this is that one needs to think like a programmer to describe your ideal phone as a set of rules like these. Not only does one have to think analytically and dissect their concept into orthogonal, machine-checkable rules, but from your examples it's also clear that for such a wide range of possibilities a whole *language* with *expressions* (at least boolean) is necessary. I see it as something like sieve. Its a pretty full language for writing rules. I, as a programmer, I do almost anything I want. For the non-programmers there are various GUIs which allow you to do all the simple tasks with a couple clicks. In fact filter email is fairly similar: if these three things are true, do X. Then I have a stack of rules and it goes through them one at time until one is true. xpath might work. There are a few options, though I would try to stay away from writing our own if it can be helps. A plan old python class might be enough with function for each possible condition. I think what we're looking for here is Prolog (or something very similar). http://en.wikipedia.org/wiki/Prolog. I'd be very interested in contributing to (and using!) a rule-based system such as this. In addition to providing an inference-based rules engine written in first order predicate logic, it has the unique ability of adding rules with side effects (basically executing native code) when certain things happen... I think it would work nicely (it basically is for this purpose). I already had plans to create a rule-based system for the moko myself (an adaptation of a prolog-like inference system that I already have under construction). Due to the memory and processing constraints on the moko and the desire to reuse code whenever possible (which I agree with wholeheartedly), I think going with Prolog is probably a better choice than trying to finish my hacked-together and unproven inference engine. Now if only my Freerunner would arrive... dunno why it's been delayed by a week before shipping. Ryan Meador __ Ryan, what approach have your efforts taken already? Any interesting insights to the problem? Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Hi, I'm one of the GSoC students and work on the answering machine. I already use this concept in my project and it uses modules so it might be possible to extend it to fit your needs. It's implemented in vala so you can use all GLib functionality and more. As far as you can create vala bindings for it or you can use C and GObject. I just implemented 2 types of connecting rules yet: all of them or one of them. Also a complex type might be possible. my current rules are: -time ( depending on day of week and current time) -calendar ( depending on your entries in you calendar ) -GPS ( depending on a GPS position and a radius around this ) my current actions are: - run a custom command on startup and at the end - answer call: yes it is an answering machine - answer asterisk call: this should also be answered - send sms: send a user defined message to a caller Here you can find the class diagram [1]. it will be updated soon. Regards, Frederik [1]: http://v1187.ncsrv.de/classes.jpeg ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
On Thu, Jul 17, 2008 at 5:01 PM, matt joyce [EMAIL PROTECTED] wrote: I have always wanted many more features on my phone, than any phone I've owned has provided. I expect the majority of people who are excited about Openmoko have similar day dreams. Exactly. I have been thinking about this too. I would love it if I had one number... My home voip line... If my computer detects via bt or wifi that I am there, it goes through, if not, it forwards to my cell number. or at work, if I am at my desk (usually not) it will ring through, else it forwards to my cell. Although this may include rules that server side, rather than client side. It would be great if some of the companies that offer a one number service which you can update online, would publish a protocol to update your settings somewhat like the dynamic dns companies, then a client program with your rulesets would update it. Here is one example of such a company that offers one number: http://www.grandcentral.com/ (just googled, there are many companies... funny just noticed google acquired them.) They aready let you update which phone to call based on your online settings. Just dreaming as well, but it probably isn't too far away. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
Alexey Feldgendler: The problem with this is that one needs to think like a programmer to describe your “ideal phone” as a set of rules like these. Not only does one have to think analytically and dissect their concept into orthogonal, machine-checkable rules, but from your examples it's also clear that for such a wide range of possibilities a whole *language* with *expressions* (at least boolean) is necessary. I'd go another way. Instead of language or script I'd talk of phone profiles. Add timeprofiles and geotags to a profile switcher and you are set. Think of it like a screensaver. You enter a tagged area (tagged silent, cause its a restaurant), phone goes silent. Same could well apply to the mistress example you provided. :) In principle this could all be implemented with a 'default timeline' and a set of geotagging tools. In addition profile would need an emergency override like in the example of the babysitter. I think I'd implement this as a feature for contact (calls from babysitter tend to be important all around, no matter what I'm doing), or a profile (elevate contact group workbuddies). This would keep it simple. It'd be GUI based. And still pretty powerful. -- Kalle Kärkkäinen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
matt joyce wrote, On 18/07/08 00:01: I have always wanted many more features on my phone, than any phone I've owned has provided. I expect the majority of people who are excited about Openmoko have similar day dreams. Absolutely. It was one of the reasons I wanted to go for a phone like the FreeRunner. I'd like to propose a rule based policy engine. In essence this would be an event based system, a service that other services could refer to, to influence their behaviour. Yes. Off the top of my head, I'd quite like my phone, when I'm at home, notify my MythTV box when a call or text message comes in. [snip] It would be quite similar to rule based filters many email systems use (outlook, thunderbird, gmail, procmail), or firewalls for that matter. Who knows, perhaps it could learn and suggest rules based on behaviour. I'm sure creative people can explore and extend this idea. Does anyone think this has merit, is achievable and worth pursuing? Yes, definitely. Not know a great deal about how the FreeRunner software is designed at the moment probably means that I would do a lot of re-inventing the wheel. However, I would've thought that if every application can generate and consume 'events', then all that is needed in your policy app is the ability to look for combinations of events (and/or states?) and generate new events that other apps can pick up? Is that what you were thinking. This has the downside that all of the 'intelligence' is in an external script/rules engine and not in the apps. That might be an 'upside'. Alternatively, each 'rule' could be it's own script which waits on certain events and then fires out new events that are picked up by the other applications to do things. Love the idea, though. Cheers Alex. Regards Matt ___ 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
Re: Rules based policy engine
Guillaume Chereau wrote: This is one of the thing I am planning to add in the framework (FSO project), although for the moment we don't focus on it too much. I agree with Alexey as well, the danger is to create something so configurable, that at the end your setting become a python script. My idea for the moment is like this : You can define a set of condition to specify the profile. For example : if at my girl friend house, profile = Paranoid Then you the application configurations can depend on the profile. e.g : If profile is Paranoid, girl_friend_number_2.block_calls = True This way, the profile is the link between the conditions set and the actions set. The number of profiles is not supposed to be too large. It is more restrictive that Russel idea, because you can't say : if time = 600, then play alarm. The only way to do so would be : if time = 600, then profile = RunAlarm if profile is RunAlarm, then alarm.run = True Which is not really useful, you don't want to create one profile for every events combination you can think of. I can see several cases where this way of doing is not the best, but I still think it is the most suitable for most practical cases. -charlie Profiles, recipes, rulesets; I think we all talking about the same thing, behaviours. It boils down to detecting a set of conditions and instructing the phone to behaviour in a certain way. Profiles are an excellent way of describing a group of common phone settings. (settings the call handling services already respect) People are familiar with the concept, they could be described by setting a phone using normal method and saving them. Perhaps if there was a default profile, and we only store differences, the delta, in other profiles, we could have cumulative profiles. That might help with the tedium of setting up every permutation and keep the number of profile down. Profiles are really just a bunch of SET actions. I still see the need for an event broker of sorts, something that will detect conditions and trigger actions. Perhaps the profile switcher (as some else mentioned) could be enhanced for that purpose. An alarm might just be a custom action, just another action. 'Run a shell command' might be the only action we need. Another poster mentioned interacting with his MythTV, one approach might be to configure the MythTV to run web server with some cgi. The phone would just use http to instigate commands. wget? If we had profiles and an event broker, all we need next is some standard way to describe the set of conditions. I'm no hardcore coder, but it seem well within the realms of possibilities. I still favour a scriptable solution, even is it wrapped in UI and machine generated. Regards Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
However, I would've thought that if every application can generate and consume 'events', then all that is needed in your policy app is the ability to look for combinations of events (and/or states?) and generate new events that other apps can pick up? Is that what you were thinking. Yes. This has the downside that all of the 'intelligence' is in an external script/rules engine and not in the apps. That might be an 'upside'. Alternatively, each 'rule' could be it's own script which waits on certain events and then fires out new events that are picked up by the other applications to do things. As I see it the trouble with each rule being an isolated process, or script, is that conflict detection might become a bit of a headache. Love the idea, though. Cheers Alex. Thank you Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Rules based policy engine
I have always wanted many more features on my phone, than any phone I've owned has provided. I expect the majority of people who are excited about Openmoko have similar day dreams. I'd like to propose a rule based policy engine. In essence this would be an event based system, a service that other services could refer to, to influence their behaviour. These devices are inherently personal, just as other computing devices are, so it reasonable to expect everyone will have slightly different requirements. The problem with a great many people wanting specific features, or personal requirements, is that some will be realised and some will not. Some requirements might be very similar, but not quite right, and some features may compete unproductively, clash. By creating a rule based policy engine, I think it would be possible to give the user the ability to describe the way their phone should work, for them, without each feature being developed for them. Here are some examples of how I would like use this concept to make my phone more personal, and how I would like to teach my phone to be smart. If it can be reliably established that my physical location is one of my favourite restaurants please switch my phone to vibrate, unless my babysitter calls. If I miss a call or I receive an SMS from from any of my work contacts during work hours, and I don't respond, please remind me. If it's not during work hours, do not take any calls from contacts exclusively in my work contacts. If my home wifi is available and my battery is not too low, don't use GPRS for data. If it a WEEKDAY and 06:00, turn on, play alarm, connect to WIFI and start getting email and rss. At 21:00 on weekdays, switch to standby. If my battery is low and I'm at home, remind me to charge. If I'm at home disable my auto-lock. Some rules would be permanent, some would be one off If John's phone is detected via bluetooth, please let me know (I need to see him, when he comes in.) Do not disturb until 13:00 (I need to get some work done) No calls until this contact calls me (I'm expecting an urgent call) Loud volume for the next hour (It's noisy here) Silent for an hour (meeting) Some events might be : - In/out calls, sms, emails - Arriving/departing somewhere - Enter/leave a time period - Discovery/loss of a bluetooth device (infer person is nearby/left) - Discovery/loss of a WIFI Similarly ,states which could be queried might be : - Call in progress - Location is within a defines area - Time is in a period - Battery is low - USB is connected Some definitions - Groups of contacts - Lists of GPS co-ords - time periods Some actions - Answer/Don't answer call - Set volume profile - switch on/off - start/stop an application - manipulate hardware It would be quite similar to rule based filters many email systems use (outlook, thunderbird, gmail, procmail), or firewalls for that matter. Who knows, perhaps it could learn and suggest rules based on behaviour. I'm sure creative people can explore and extend this idea. Does anyone think this has merit, is achievable and worth pursuing? Regards Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
On Fri, 18 Jul 2008 01:01:08 +0200, matt joyce [EMAIL PROTECTED] wrote: If it can be reliably established that my physical location is one of my favourite restaurants please switch my phone to vibrate, unless my babysitter calls. If I miss a call or I receive an SMS from from any of my work contacts during work hours, and I don't respond, please remind me. If it's not during work hours, do not take any calls from contacts exclusively in my work contacts. If my home wifi is available and my battery is not too low, don't use GPRS for data. If it a WEEKDAY and 06:00, turn on, play alarm, connect to WIFI and start getting email and rss. At 21:00 on weekdays, switch to standby. If my battery is low and I'm at home, remind me to charge. If I'm at home disable my auto-lock. The problem with this is that one needs to think like a programmer to describe your “ideal phone” as a set of rules like these. Not only does one have to think analytically and dissect their concept into orthogonal, machine-checkable rules, but from your examples it's also clear that for such a wide range of possibilities a whole *language* with *expressions* (at least boolean) is necessary. Moreover, if one *is* a programmer, and has learned the rule expression language, there will be bugs in the rulesets, like overlooked priorities or excessively permissive conditions, and you'll spend some time debugging it, probably missing a few important calls and alarms now and then in the process. Next step would be debugging tools for rulesets, allowing to simulate times of day, different conditions and incoming events to test the rules. Next, backup and revision control for rulesets. This is where madness lies: you have to modify and debug a program in a declarative logic language when you start dating someone because it breaks all your carefully polished ruleset. Sounds like a topic for XKCD. Randall, are you by any chance reading this? I understand that you must be thinking, “This phone is fully programmable, so I can make it do whatever I want”. True. Now, by defining sets of possible conditions and actions and letting the user make rules out of these, you're basically saying: “Here is a computer. You can program it to do whatever you want”. While this might be usable for someone who is a programmer (and who's willing to be a programmer when they deal with their cell phone), it's not a killer application. It's an absence of application; it's rather an interpreter for a programming language in which a user can write themself a killer application. The key to making a phone do what you, I or someone else wants is rather in analyzing our requirements and figuring out what parts are constant and what are changing. Of course, all people want different things, and the same person wants different things at different times. But the number of dimensions in the space of all reasonable people's demands is still much less than that of the space of all possible rulesets. Only a small subset of all possible rules, let alone rulesets, makes any sense at all, while the vast majority is nonsensical, such as “When WiFi is available and John's phone is nearby, mute all calls”, or “If I have unread SMS on Thursday, prefer GPRS”. Analyzing and isolating the axes of user demands is much harder than developing a ruleset-driven engine, but at least it has a chance of becoming usable. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
I agree with most of what Alexey said, but I would love to see some sort of easy to use scripting / gui environment. I think the FSO stuff is working on some sort of d-bus event notification system. Presumably there's a set of python / c libraries that know how to talk to dbus, and provide a simple wrapper on top of everything. (I haven't looked at FSO or DBUS yet... ;) I wonder if this is a job for some simple query language like a subset of xpath or xquery. It could re-evaluate an expression each time a dbus event could change the expression's results. It would also simplify writing things like pause my music when the phone rings, alarm clocks, etc: register_event_handler(/phone/incoming_call = true, mute_music_callback) register_event_handler(/clock/time = 600, play_alarm_callback, loud_buzzer.ogg) and so on... These event handlers could live in a python script (or, better) inside a simple GUI app. I think most people that own one of these things knows how to program. Improving their productivity a bit should be a big win when the consumer version of the phone ships... -Rusty Alexey Feldgendler wrote: On Fri, 18 Jul 2008 01:01:08 +0200, matt joyce [EMAIL PROTECTED] wrote: If it can be reliably established that my physical location is one of my favourite restaurants please switch my phone to vibrate, unless my babysitter calls. If I miss a call or I receive an SMS from from any of my work contacts during work hours, and I don't respond, please remind me. If it's not during work hours, do not take any calls from contacts exclusively in my work contacts. If my home wifi is available and my battery is not too low, don't use GPRS for data. If it a WEEKDAY and 06:00, turn on, play alarm, connect to WIFI and start getting email and rss. At 21:00 on weekdays, switch to standby. If my battery is low and I'm at home, remind me to charge. If I'm at home disable my auto-lock. The problem with this is that one needs to think like a programmer to describe your “ideal phone” as a set of rules like these. Not only does one have to think analytically and dissect their concept into orthogonal, machine-checkable rules, but from your examples it's also clear that for such a wide range of possibilities a whole *language* with *expressions* (at least boolean) is necessary. Moreover, if one *is* a programmer, and has learned the rule expression language, there will be bugs in the rulesets, like overlooked priorities or excessively permissive conditions, and you'll spend some time debugging it, probably missing a few important calls and alarms now and then in the process. Next step would be debugging tools for rulesets, allowing to simulate times of day, different conditions and incoming events to test the rules. Next, backup and revision control for rulesets. This is where madness lies: you have to modify and debug a program in a declarative logic language when you start dating someone because it breaks all your carefully polished ruleset. Sounds like a topic for XKCD. Randall, are you by any chance reading this? I understand that you must be thinking, “This phone is fully programmable, so I can make it do whatever I want”. True. Now, by defining sets of possible conditions and actions and letting the user make rules out of these, you're basically saying: “Here is a computer. You can program it to do whatever you want”. While this might be usable for someone who is a programmer (and who's willing to be a programmer when they deal with their cell phone), it's not a killer application. It's an absence of application; it's rather an interpreter for a programming language in which a user can write themself a killer application. The key to making a phone do what you, I or someone else wants is rather in analyzing our requirements and figuring out what parts are constant and what are changing. Of course, all people want different things, and the same person wants different things at different times. But the number of dimensions in the space of all reasonable people's demands is still much less than that of the space of all possible rulesets. Only a small subset of all possible rules, let alone rulesets, makes any sense at all, while the vast majority is nonsensical, such as “When WiFi is available and John's phone is nearby, mute all calls”, or “If I have unread SMS on Thursday, prefer GPRS”. Analyzing and isolating the axes of user demands is much harder than developing a ruleset-driven engine, but at least it has a chance of becoming usable. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
On Fri, Jul 18, 2008 at 9:59 AM, Alexey Feldgendler [EMAIL PROTECTED] wrote: On Fri, 18 Jul 2008 01:01:08 +0200, matt joyce [EMAIL PROTECTED] wrote: If it can be reliably established that my physical location is one of my favourite restaurants please switch my phone to vibrate, unless my babysitter calls. If I miss a call or I receive an SMS from from any of my work contacts during work hours, and I don't respond, please remind me. If it's not during work hours, do not take any calls from contacts exclusively in my work contacts. If my home wifi is available and my battery is not too low, don't use GPRS for data. If it a WEEKDAY and 06:00, turn on, play alarm, connect to WIFI and start getting email and rss. At 21:00 on weekdays, switch to standby. If my battery is low and I'm at home, remind me to charge. If I'm at home disable my auto-lock. The problem with this is that one needs to think like a programmer to describe your ideal phone as a set of rules like these. Programmers are people too. :) Not only does one have to think analytically and dissect their concept into orthogonal, machine-checkable rules, but from your examples it's also clear that for such a wide range of possibilities a whole *language* with *expressions* (at least boolean) is necessary. Yes, this is precisely what I want, although it need not be overly complex. Thunderbird's filter system is easy enough, MokoRules would be more complex, but the process can be broken down into small steps. http://opensourcearticles.com/nidelven/website/articles/thunderbird_15/english/part_07_images/1126606659X51 I've always thought Outlook's rules wizard was pretty good. http://pubs.logicalexpressions.com/pub0009/LPMArticle.asp?ID=415 I'm frequently impressed by non-technical staff at work, who write rules to make their outlook work for them. Moreover, if one *is* a programmer, and has learned the rule expression language, there will be bugs in the rulesets, like overlooked priorities or excessively permissive conditions, and you'll spend some time debugging it, probably missing a few important calls and alarms now and then in the process. Next step would be debugging tools for rulesets, allowing to simulate times of day, different conditions and incoming events to test the rules. Next, backup and revision control for rulesets. This is where madness lies: you have to modify and debug a program in a declarative logic language when you start dating someone because it breaks all your carefully polished ruleset. Agreed. This is about granularity, and the examples I gave were off the cuff and may well be unworkable in RL. Sanity check can be developed too, and packaged in groups to meet the needs for Novice, Competent, Pro. Freedom to make mistakes. Sounds like a topic for XKCD. Randall, are you by any chance reading this? I know what you mean. I understand that you must be thinking, This phone is fully programmable, so I can make it do whatever I want. True. Now, by defining sets of possible conditions and actions and letting the user make rules out of these, you're basically saying: Here is a computer. You can program it to do whatever you want. While this might be usable for someone who is a programmer (and who's willing to be a programmer when they deal with their cell phone), it's not a killer application. It's an absence of application; it's rather an interpreter for a programming language in which a user can write themself a killer application. Yes, that's what I want, I'd be happy with text config files to start with. Even an offline webapp to make/test the rules, is not disagreeable to me. People could publish their recipes, rulesets. The key to making a phone do what you, I or someone else wants is rather in analyzing our requirements and figuring out what parts are constant and what are changing. Of course, all people want different things, and the same person wants different things at different times. But the number of dimensions in the space of all reasonable people's demands is still much less than that of the space of all possible rulesets. Only a small subset of all possible rules, let alone rulesets, makes any sense at all, while the vast majority is nonsensical, such as When WiFi is available and John's phone is nearby, mute all calls, or If I have unread SMS on Thursday, prefer GPRS. Analyzing and isolating the axes of user demands is much harder than developing a ruleset-driven engine, but at least it has a chance of becoming usable. This reminds me of a Richard Dawkins quote, speaking about the search space of DNA, But, however many ways there may be of being alive, it is certain that there are vastly more ways of being dead, or rather not alive. I think what your saying is that the more variables there are, the more possibilities of non-useful, or counter productive rules there will be. If you are, then I
Re: Rules based policy engine
I understand that you must be thinking, This phone is fully programmable, so I can make it do whatever I want. True. Now, by defining sets of possible conditions and actions and letting the user make rules out of these, you're basically saying: Here is a computer. You can program it to do whatever you want. While this might be usable for someone who is a programmer (and who's willing to be a programmer when they deal with their cell phone), it's not a killer application. It's an absence of application; it's rather an interpreter for a programming language in which a user can write themself a killer application. Personally I think this sounds pretty awesome, and I'd love to play around hacking together some useful rules, but it wouldn't be just end-users writing the rules - there could be simple front ends that use this engine for implementation. Many people would want their phone to have this kind of intelligent behaviour, but the exact behaviour needed is different. Having a good engine to do the common stuff (checking location, checking time, blocking calls, changing alert profiles, etc.) avoids duplication of effort and allows more people to focus on users' requirements rather than re-implementing the basics over and over. Yes, that's what I want, I'd be happy with text config files to start with. Even an offline webapp to make/test the rules, is not disagreeable to me. People could publish their recipes, rulesets. Indeed! Similar to the Stylish/Greasemonkey/Adblock Firefox extensions, which seem to be fairly popular :-). Ben ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
The problem with this is that one needs to think like a programmer to describe your ideal phone as a set of rules like these. Not only does one have to think analytically and dissect their concept into orthogonal, machine-checkable rules, but from your examples it's also clear that for such a wide range of possibilities a whole *language* with *expressions* (at least boolean) is necessary. I see it as something like sieve. Its a pretty full language for writing rules. I, as a programmer, I do almost anything I want. For the non-programmers there are various GUIs which allow you to do all the simple tasks with a couple clicks. In fact filter email is fairly similar: if these three things are true, do X. Then I have a stack of rules and it goes through them one at time until one is true. xpath might work. There are a few options, though I would try to stay away from writing our own if it can be helps. A plan old python class might be enough with function for each possible condition. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
On Fri, Jul 18, 2008 at 11:55 AM, Steven Kurylo [EMAIL PROTECTED] wrote: The problem with this is that one needs to think like a programmer to describe your ideal phone as a set of rules like these. Not only does one have to think analytically and dissect their concept into orthogonal, machine-checkable rules, but from your examples it's also clear that for such a wide range of possibilities a whole *language* with *expressions* (at least boolean) is necessary. I see it as something like sieve. Its a pretty full language for writing rules. I, as a programmer, I do almost anything I want. For the non-programmers there are various GUIs which allow you to do all the simple tasks with a couple clicks. In fact filter email is fairly similar: if these three things are true, do X. Then I have a stack of rules and it goes through them one at time until one is true. xpath might work. There are a few options, though I would try to stay away from writing our own if it can be helps. A plan old python class might be enough with function for each possible condition. Sieve - http://en.wikipedia.org/wiki/Sieve_(mail_filtering_language) xpath - http://en.wikipedia.org/wiki/XPath ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Rules based policy engine
This is one of the thing I am planning to add in the framework (FSO project), although for the moment we don't focus on it too much. I agree with Alexey as well, the danger is to create something so configurable, that at the end your setting become a python script. My idea for the moment is like this : You can define a set of condition to specify the profile. For example : if at my girl friend house, profile = Paranoid Then you the application configurations can depend on the profile. e.g : If profile is Paranoid, girl_friend_number_2.block_calls = True This way, the profile is the link between the conditions set and the actions set. The number of profiles is not supposed to be too large. It is more restrictive that Russel idea, because you can't say : if time = 600, then play alarm. The only way to do so would be : if time = 600, then profile = RunAlarm if profile is RunAlarm, then alarm.run = True Which is not really useful, you don't want to create one profile for every events combination you can think of. I can see several cases where this way of doing is not the best, but I still think it is the most suitable for most practical cases. -charlie On Thu, 2008-07-17 at 17:46 -0700, Russell Sears wrote: I agree with most of what Alexey said, but I would love to see some sort of easy to use scripting / gui environment. I think the FSO stuff is working on some sort of d-bus event notification system. Presumably there's a set of python / c libraries that know how to talk to dbus, and provide a simple wrapper on top of everything. (I haven't looked at FSO or DBUS yet... ;) I wonder if this is a job for some simple query language like a subset of xpath or xquery. It could re-evaluate an expression each time a dbus event could change the expression's results. It would also simplify writing things like pause my music when the phone rings, alarm clocks, etc: register_event_handler(/phone/incoming_call = true, mute_music_callback) register_event_handler(/clock/time = 600, play_alarm_callback, loud_buzzer.ogg) and so on... These event handlers could live in a python script (or, better) inside a simple GUI app. I think most people that own one of these things knows how to program. Improving their productivity a bit should be a big win when the consumer version of the phone ships... -Rusty Alexey Feldgendler wrote: On Fri, 18 Jul 2008 01:01:08 +0200, matt joyce [EMAIL PROTECTED] wrote: If it can be reliably established that my physical location is one of my favourite restaurants please switch my phone to vibrate, unless my babysitter calls. If I miss a call or I receive an SMS from from any of my work contacts during work hours, and I don't respond, please remind me. If it's not during work hours, do not take any calls from contacts exclusively in my work contacts. If my home wifi is available and my battery is not too low, don't use GPRS for data. If it a WEEKDAY and 06:00, turn on, play alarm, connect to WIFI and start getting email and rss. At 21:00 on weekdays, switch to standby. If my battery is low and I'm at home, remind me to charge. If I'm at home disable my auto-lock. The problem with this is that one needs to think like a programmer to describe your “ideal phone” as a set of rules like these. Not only does one have to think analytically and dissect their concept into orthogonal, machine-checkable rules, but from your examples it's also clear that for such a wide range of possibilities a whole *language* with *expressions* (at least boolean) is necessary. Moreover, if one *is* a programmer, and has learned the rule expression language, there will be bugs in the rulesets, like overlooked priorities or excessively permissive conditions, and you'll spend some time debugging it, probably missing a few important calls and alarms now and then in the process. Next step would be debugging tools for rulesets, allowing to simulate times of day, different conditions and incoming events to test the rules. Next, backup and revision control for rulesets. This is where madness lies: you have to modify and debug a program in a declarative logic language when you start dating someone because it breaks all your carefully polished ruleset. Sounds like a topic for XKCD. Randall, are you by any chance reading this? I understand that you must be thinking, “This phone is fully programmable, so I can make it do whatever I want”. True. Now, by defining sets of possible conditions and actions and letting the user make rules out of these, you're basically saying: “Here is a computer. You can program it to do whatever you want”. While this might be usable for someone who is a programmer (and who's willing to be a programmer when they deal with
