TRestManager : managing REST core classes

This class, as its name suggests, manages all other REST core classes, including TRestRun, TRestProcessRunner, and so on. A REST core class has a poniter to its manager, thus it can easily get access to its sibling core classes. For example, a process class can get access to its sibling TRestRun, and acquires matadata in it.

TRestManager performs initialization for its managed core classes by a strategy called sequential start up. For example, inside the rml configuration file, there is a section declared as "TRestManager". And in this section there is some child sections declared by different core class names(here we have "TRestRun", "TRestProcessRunner"). TRestManager will try to instantiate objects of corresponding core classes by calling the method TClass::GetClass(). Then it call the core classes' LoadConfigFromFile() method giving them the defined child sections. If the core class also contains TRestMetadata-inherited class which can be initialized through rml file/sections, its section will have its own child section(here we have "TRestDetectorReadout"). And this grandchild section is given to the grand-resident class in that core class. This is sequential startup.

<TRestManager ... >
  <globals>
    ...
  </globals>
  
  <TRestRun ... >
    <TRestDetectorReadout ... >
      ...
    </TRestDetectorReadout>
  </TRestRun>
  
  <TRestProcessRunner ...>
    ...
  </TRestProcessRunner>
  
  <addTask .../>
  
</TRestManager>

In short, we perform sequential startup by constructing a same hierarchy in rml file with REST classes, providing a more readable text for both codes and configurations.