Read through this step by step if this is the firrst time through...
The system consists of the following components:
Some definitions:
The data generator objects are the primary source of data in the system. Each data generator object is responsible for a single stream of data, even if physically the streams come from the same source (i.e. begin run, end run, event, etc.).
The data generator knows about time, and, more specifically, it knows the time at which its stop points occur. For example, in an event stream, the stop points occur on every event, and the data generator knows when these occured (in time).
Associated with each data generator is a list of actions. Each time a stream is informed it has hit a stop point it calls all of its actions. The arguments to the action are defined by the stream. The actions are executed in a defined order. Normally they are executed in response to the coordinator informing a data generator that it has reached its next stop point.
The action object is actually an abstract object. Each data generator author subclasses the Action object and provides a process method that takes, as arguments, whatever the data generator thinks is required.
Because the call protocal is up to each data stream, the Action's return values are also defined by each data stream, as are the behaviors. You may, for example, want to quit processing further actions when one returns false.
Associating an action with a data generator is done by the main program, with a call to the action object.
The data generator object also has methods that allow the careful ordering of the action objects, in situations where that is important (as it often is!).
The coordinator is the master of the whole operation. It keeps track of a list of data generators. For each data generator it knows the next stop time. Each time the go_to_next_stop method is called the coordinator sends the data generator with the closest stop time a execute_actions_for_next_stop_time to invoke the data generator's action list. Finally, the coordinator queries the data generator for its next stop time and updates its ordered list of stop times.
The coordinator's go_to_next_stop method is called repeatedly by the main program.
The main program is quite simple. It creates the data stream objects and action objects. It then adds the actions to the data stream objects, and finally adds the data stream objects to the coordinator. Finally, it loops till one of the data stream objects informs the coordinator it is out of stops.
I very much doubt that the main program, in reality, will be anything close to what is listed in the example above. As such there are two possible approaches.
Other than that, I've not given much thought to how the UI would work.
The following picture shows what the various users and authors are required to write to get the system to run.
