Plan for providing default handlers - September 2011¶
13-Sep-2011, KAB - This page has notes on the features and design considerations that I want to keep in mind as we add default message handlers to the RunControlReceiver class.
The goal of adding default handlers to the RCReceiver library is that each application that uses it will automatically reply to each Run Control message even if the application hasn't explicitly specified a handler for every message type. In this way, the Run Control code can be cleaner since RC can always expect a response from every process for every message.Notes:
- At the moment, I don't know of any way to automatically create the necessary default handlers by looking at the message definitions in the DAQMessages package. So that means that if we add a message type to DAQMessages, we have to remember to add it to the RCReceiver library.
- As part of this work, I should combine the RCReceiver and GTReceiver classes.
- The RCReceiver class should install a default handler for each known message type at construction time. Application-specific handlers should over-ride a default handler, but we probably need to continue to support multiple application-specific handlers per message type. (The existing method is "addListener", not "setListener".)
- Wait, this can't be done at construction time, since we only know about the null partition at construction time. Then, let's say that the first time that any handler is specified for a partition, we install the default handlers for that partition.
- We should not install a default handler for the StatusRequest message. We should force the application to create one itself. [Jon]
- Should we return a special status code from default handlers to that Run Control could tell whether a given reply was from a default or application-specified handler, if it cared?
- If multiple RunControlReceiver instances are created by a single application, only one of them should install defaults.