Implementing a module

Modules are atomic units designed to perform tasks on events. They can read all the information contained in Event and, if needed, they can also modify the Event piece that the software administrator allowed to write. We encourage the developer not to write fat modules with thousands lines of code, all the leading code should be arranged in service classes to ensure code reusability. Therefore modules have to be intended as interfaces between Diana and service classes performing all the leading operations.

Modules have to implement at least the three following methods:

• Init: It is executed before the event loop, put here all the code you need before event processing. It should be intended as a constructor operator, so we suggest to put here all the initialization code, leaving the constructor empty. You should put here things like members initialization, file opening, config file parameters reading etc...
• Do: It is executed for each event in the event loop. Here you can get all the Event members and use them within service classes. You can also set the Event members that this module has permission to write (see 9).
• Done: It is executed at the end of the event loop. It should be intended as a destructor operator, so put here all the delete and free instructions, file closing etc... leaving the destructor empty.

Modules can control the Diana flow by executing again the Sequence they belong to, this feature has been designed for algorithms that need multiple iterations. In order to perform this operation use the following methods:

• SetRunAgain: Set that the Sequence have to be executed another time or not (default).
• GetRunAgain: Get that the Sequence is being executed another time or not.
• GetIteration: Get the number of times the Sequence has been executed so far.

Modules can save temporary data, i.e. objects that will not be written in output files and live only inside the Diana run. These object are useful to share informations beetwen modules that doesn't need to be dumped on output files:

• Event AuxData: use the Event method AuxData to access temporary data stored in each event. These data live only in the event loop and get lost even if the Sequence is run another time.
• Sequence AuxData: use the Module method SeqAuxData to access temporary data stored in the current sequence. These data remains alive even if the Sequence is run another time.

Instead of using the usual printf or cout output stream functions use the following commands that support the printf syntax, each of them will print messages on the screen only if the verbose level set in the config file is greater equal than the used one:

• Debug: code debugging
• Info: general information
• Warn: an error that Diana can handle and fix.
• Error: an error that Diana cannot handle but that doesn't cause the stop of Diana run.
• Panic: an error that Diana cannot handle that causes the stop of the Diana run.

Modules can read configuration parameters from config file. if the parameter is not found the default value provided by the user is used. Available methods are: GetInt, GetDouble, GetString, GetBool. Below is a config file entry example for a generic module:

module ModuleName ##mandatory parameters # set verbosity level verbosity = info # set if the module have to be loaded enable = true # set if the module have save data into the event or not. storedata = true ##module specific parameters myvarint = 1 myvardouble = 1.0 myvarstring = hellocuore! myvarbool = true endmod