Live Model

This document will describe the live model used by madz.

Daemon Server

This is the core managing component of the live setup. The Daemon Server is a server which is started for each madz based project. In reality it can manage more than one at a time.

The server is generally responsible for handling the threading model and loading madz plugins for different purposes.

Commands:

• "identity-concepts": Describes the concepts of identity the daemon provides. Including serialization methods for how to transmit them over the wire. Need to come up with how to represent this.
• "minion": notifies the server it expects a handler based on the object passed which is an identity method supported by the server. The server will try to create an instance of the handler, potentially loading a plugin. It will return either an error report, or a success report containing the information about how to connect to the handler. May return the same handler multiple times if allowed by the handler.
• "describe-minions": Returns a report containing all of the handlers currently being managed by the daemon server.
• "banish": Destroys the daemon and it's minions.

Minions are a nickname fir handlers.

Madz Created Handlers

The daemon will also be responsible for handling internal handlers. It will create these through the same interface, albeit without a network connection, as the above.

It can then create sub-processes which communicate with the handler it created. Eventually this will be automatic through the interplugin layer.

Current Minions

These are raw python minions:

• "command": Takes command strings and processes them one at a time. A singleton.
• "ipython": Starts a thread with an ipython kernel in it.
• "executer": A manager minion for an execution of the plugin system.