5.2.1. ModuleBrain

Most of the brains for specific modules share at least some functionality. Nearly all need to generate markov text, nearly all want to handle old vs new formatted names etc.

class ModuleBrain.ModuleBrain(user, brain)

This is the abstract superclass for brains for specific modules.

Print()

Print the current selection/document/screen/whatever it means to this app.

exit(save=False)

Close the application

Parameters:

• save: for modules that use it, whether to save before exiting

get_actions(base)

Load the actions this module will use, returning a ChooserBase instance.

Return: an instance of ChooserBase for the actions this Brain will perform

get_mod_name()

Return the module name which this brain maps to

get_user_apps()

For most modules our name is the same as the user app this uses so we will return that.

handle_negotiation(conn)

Negotiate with the potential partner on the other end of the connection. This is called after this brain posted to the whiteboard asking for partners to do a task. When someone offers to be such a partner the two sides have to agree to how it will actually be done, and whether or not it can be done.

is_failed()

Each module can add its own criteria to detect that it is in a failed state. The MarkovBrain already has some general checks, but this provides a space for custom checks specific to a type of activity.

is_ready()

Return: True if this module is in a ready state, False otherwise

is_user_app()

Return True iff the user needs to have this module name as an app

load_preaction_checks()

Attempt to find any suitable preaction checks for this module

open()

Open the user’s application

preaction_check()

This is a placeholder that defaults to doing nothing and saying it is ok to continue. Subclasses may well want to implement their own version of this. It is called just prior to invoking each action.

Instances should perform any extra steps that are required. One use of this would be, for example, to have a brain look for certain triggers like receiving an email from a certain sender that must be read as soon as it arrives.

If this function returns False the controller should not assume that the next action is safe to run.

Return: True if the next action can be run, False otherwise

reset_ready_state()

The module might have previously failed to run and be marked as “not ready” so this is a way for the main brain to clear that state when the next iteration is ready to begin.

restart()

This is a default implementation to restart the app.

should_use_iodine(domain)

Given a dest domain, decide whether or not the user should use iodine for this, and if so whether it should be a long- or short-running instance.

Parameters:

• domain: the name of the domain that will be the target of iodine

Return: if iodine should not be started will return DO_NOT_START

If it should be started then immediately stopped: SHORT_START If it should be started and left running: LONG_START

start_iodine(shell, domain)

start the iodine client

stop_iodine(shell, domain)

stop the iodine client associated with the given domain