Event Responder.

Idea

A small desktop daemon that responds to events in the system.

Reasoning

We have a selection of daemons that respond to various events. It would be good to have one daemon that manages all these events from a central place and is controlled by a set of control scripts.

Examples

Fred plugs in his ipod, the dbus sends an event, the daemon notices this and runs all the scripts that are relevent for that event, the device is mounted, and gtkpod is launched.

Fred just wants to have the ipod only mounted at plug in and he will run gtkpod if he wants so he goes to event_manger properties and look through recent events to find the ipod plugin and turns off that event.

Wilma decides that she wants to run rhythmbox when her ipod is plugged in and so goes to event_manager and finds the ipod settings where she enteres in her own script to be run on plug in.

Gorgena unplugs her ac power and the screen is dimmed to save on power.

Harry has a blinder of an idea for launching a monitoring daemon for his usb powered coffee mat so he writes the relevent scripts and a config and installs that in the correct dir to make it work. Once he is happy with these settings he sends the config upstream.

Overview of Design

There will be a single daemon that listens on the dbus for events, for each event it checks through it's own list and decides if it needs to take an action. if it does then it runs the relevant scripts. There will be a single config file for the events that will have the following format

<xml>
<events>
  <event><dbus>dbus.power.ac.unplugged</dbus>
     <action>
                <description>Dim the Screen</description>
                <optional/>
                <script priority=10>/usr/share/event_manager/dim_screen</script>
              </action>
  </event>
</event>
</xml>

This will be compiled from a selection of other config files to create a large file #XXX This could be a python pickle that is remade whenever it notices that the config files have been changed. Either system wide or stored locally, keep disk reads down.

Parts

1. Config
2. Monitor
3. App runner.

1. Config

Each service to be monitored will have a config file that gives the following infomation:

• dbus_id - The dbus id to listen on
• dbus_events - The envents on the above id to react to
• reaction - Each of the events above should have a reaction
• test - This can be a test for various paramaters given from the dbus signal, also should detect flappyness and repeats.
• action - This can either be another dbus response, a popup, a notification, or run a script.

For version 1.0 should just be a simple python config file as follows

[global]

[monitor_name]
dbus=dbus.freedesktop.org.wibble
dbus_event=WibbleOn
reactions=reaction_wibble_on,reaction_std_notify

[reaction_wibble_on]
test=test_ison
action=script
script_name="/usr/local/bin/asdf"

Note: This should be extendable to setup other things to be monitrored, temps, diskspace etc, although this should be done via dbus to keep this small and neat. You want disk monitoring then create a cron job or daemon that creates the correct dbus output then create a monitor config as above to trigger actions. Note: There may also be a need to track some dependenceys so that if the network goes down don't bother me with all the offline messages. Could just be some sort of dbus checks. Not needed for version 1.0!

2. Monitor

This is the main body of the beast this sits listening on the dbus for signals that it knows about from the config above and responds in the correct way.

3. App runner

This is a seperate thread/program that runs the various responses, this should not block the monitor and allow various things to be reported at once.