5.9. Triggered Events

ConsoleUser has an ability to look for some condition to be met, and if it is to detour its normal Markov brain activity into an alternate script, then resuming the Markov activity afterward.

For example, a triggered event might be to have ConsoleUser click on a link in an email when a message with a certain subject is received. In this case, ConsoleUser will need to know that it has to take an action when that subject comes in, and also what to do when it is seen.

Triggered events add the concept of a scenario to ConsoleUser. A scenario allows the user to take some specific actions when appropriate while behaving as a typical ConsoleUser instance at all other times.

5.9.1. How it Works

Triggered events are considered to be different scenarios, or at least pieces of them. As ConsoleUser can be used with much the same user config for many scenarios, several files will try to be loaded during the user’s startup, and those will allow some sets of scenario actions to be used every time and some to apply only to certain configurations.

In the user.conf file it is possible to specify a key scenarioDir which, hopefully intuitively, defines the directory containing the scenario files that define triggered events. It is also possible to specify either in the user.conf or with a -s <name> argument to Controler.py a qualifier that will list certain files that should only be loaded for that specific configuration.

The files in the directory will be imported by forming names of modules that should be used if they are present. Each ConsoleUser module, e.g., WebBrowser or EmailClient, will try to load relevant trigger modules when they are loaded–so if a scenario directory contains scenario files for modules that this User is not configured to use, those will not be loaded.

The modules, and therefore filenames, will be to match the module’s name and append the scenario ID to that. It the unadorned name and the name with Generic appended will also be loaded if they are present, but those latter two will be loaded for every configuration, not just those matching the scenarioID.

So when the Blog module loads if we specify a -s Demo argument the following files in the scenarioDir will be loaded if they are present: BlogDemo.py, BlogGeneric.py, and Blog.py. They are loaded in that order, and the first of those that is successfully imported and has an _init() function that can be called “wins” and stops the rest of the search.

When the module is loaded all of the functions in it will be listed. Any function that does not begin with an underscore will be considered a triggerable function, and will be added to the list for the current module.

While a module is active under the Markov Brain it normally chooses a new action and executes that automatically after each action finishes. If there are any loaded triggers, each of those functions will be called prior to beginning the next action. The function should first check to see if it is appropriate for it to do its task, and if not immediately exit. Each function should return True if the application is still ready for use. Any value that evaluates to False indicates to the Brain that it should not proceed with the action it was planning. Indeed, a False value will cause the Brain to declare the current time in that module over and go to select the next module based on the Markov model it is using (which could be the same one depending on the transition matrix).