Project

General

Profile

MessageFacility and Configuration Language discussion

On 25 August 2010 we had a meeting to discuss issues regarding the MessageFacility and the configuration language, and changes that need to these packages if we are to move art to use the external packages rather than its inherited, internal versions of them.

Note: FHiCL is Fermilab Hierarchichal Configuration Langauge, the newly-proposed name for the configuration language.

The issues covered were restricted to:
  • MessageLogger and MessageService internal libraries vs. MessageFacility external package
  • ParameterSet library and Python configuration library vs. external packages

Uncertainties

This is a list of uncertainties we started with:

  1. How much effort would be required to make the existing Python-based system build under cmake, and to get it installed into our newly-defined "build environment" and "installed environment"?
  2. How much effort is required to modify existing art code to use the interface of the ParameterSet class in the external package version?
  3. How much effort is required to replace all the existing Python configuration files with FHiCL documents?
  4. How much effort is required to add the preprocessor (to handle include statements) to the parser?
  5. How much effort is required to encode the top-level design of Python configuration documents in FHiCL?

Choices we could make

  1. Keep the old versions of everything during the sprint; change over to the new versions at some later date.
  2. Do partial changes now: MessageFacility configuration using new configuration language, other things using the old Python
  3. Cut over to the new products during the sprint.

Item number 2 seems the least attractive.

Status of MessageFacility

  • Used by NoVA, mostly they use the "remote" destinations
  • Depends on DDS, but the dependency should not be hard to remove
  • Code is in "mf" namespace; we need to change art code from expecting "edm" namespace to use of "mf" namespace
  • Does not provide the MessageService. Mark raised questions about the continued need for the MessageService. We need to evaluate whether art should keep a facility like MessageService, or use the MessageFacility directly
  • We need to establish, for art, a set of rules for the the MessageFacility's "module/event" concepts (for labeling and summarizing output) should be mapped; NoVA does the organization by thread which seems not to be appropriate for art.
  • We would like to break up the MessageFacility package into several independent parts, as noted below.

Proposed package organization

Currently the MessageFacility package contains also DDS facilities, the ParameterSet class, and the C++ version of the parser for FHiCL.
We want to break this up into the several package, with the following dependencies.

ParameterSet is used by MessageFacility
ParameterSet is used by FHiCL-C++
MessageFacility is used by MessageFacility-DDS
DDS is used by MessageFacility-DDS
MessageFacility-DDS is used by NoVA code base
FHiCLC++ is used by art
MessageFacility is used by art

Tasks to be done during the switch

These tasks are sorted into priority groups; within the group priorities are equal.

  • Priority 1 tasks: need to be done for code to build
    1. repackaging of MessageFacility into the package organization suggested above
    2. changing art source code to use the "mf" namespace rather than "edm" namespace
    3. changing art source code to use the new ParameterSet class interface
    4. make the appropriate art element start the MessageFacility
  • Priority 2 tasks
    1. Map the MessageFacility "module/event" concepts into appropriate art features
    2. Add the preprocessor to the C++ version of the configuration language parser
  • Priority 3 tasks
    1. Modify the C++ version of the configuration language parser to match the formal description of the language