+ * The base class passes all relevant parameters for data access directly on to the
+ * component. Input blocks can be accessed by means of the array <tt> blocks </tt>.
+ * Output data are written directly to shared memory provided by the pointer
+ * <tt> outputPtr </tt> and output block descriptors are inserted directly to the
+ * list <tt> outputBlocks </tt>.
+ *
+ * \b NOTE: The high-level input data access methods can be used also from the low
+ * level interface. Also the PushBack functions can be used BUT ONLY if no data is
+ * written to the output buffer and no data block descriptors are inserted into the
+ * output block list.
+ *
+ * @section alihltcomponent-initialization Component initialization and configuration
+ * The component interface provides two optional methods for component initialization
+ * and configuration. The @ref DoInit function is called once before the processing.
+ * During the event processing, a special event can trigger a reconfiguration and the
+ * @ref Reconfigure method is called. There are three possible options of initialization
+ * and configuration:
+ * - default values: set directly in the source code
+ * - OCDB objects: all necessary information must be loaded from OCDB objects. The
+ * Offline Conditions Data Base stores objects specifically valid for individual runs
+ * or run ranges.
+ * - Component arguments: can be specified for every component in the chain
+ * configuration. The arguments can be used to override specific parameters of the
+ * component.
+ *
+ * As a general rule, the three options should be processed in that sequence, i.e
+ * default parameters might be overridden by OCDB configuration, and the latter one
+ * by component arguments.
+ *
+ * @subsection alihltcomponent-initialization-arguments Component arguments
+ * In normal operation, components are supposed to run without any additional argument,
+ * however such arguments can be useful for testing and debugging. The idea follows
+ * the format of command line arguments. A keyword is indicated by a dash and an
+ * optional argument might follow, e.g.:
+ * <pre>
+ * -argument1 0.5 -argument2
+ * </pre>
+ * In this case argument1 requires an additional parameter whereas argument2 does not.
+ * The arguments will be provided as an array of separated arguments.
+ *
+ * Component arguments can be classified into initialization arguments and configuration
+ * arguments. The latter are applicable for both the @ref DoInit and @ref Reconfigure
+ * method whereas initialization arguments are not applicable after DoInit.
+ *
+ * @subsection alihltcomponent-initialization-ocdb OCDB objects
+ * OCDB objects are ROOT <tt>TObjects</tt> and can be of any type. This is in particular
+ * useful for complex parameter sets. However in most cases, a simple approach of human
+ * readable command line arguments is appropriate. Such a string can be simply stored
+ * in a TObjString (take note that the TString does not derive from TObject). The
+ * same arguments as for the command line can be used. Take note that in the TObjString
+ * all arguments are separated by blanks, instead of being in an array of separate
+ * strings.
+ *
+ * The base class provides two functions regarding OCDB objects:
+ * - LoadAndExtractOCDBObject() loads the OCDB entry for the specified path and extracts
+ * the TObject from it.
+ * - ConfigureFromCDBTObjString() can load a number of OCDB objects and calls the
+ * argument parsing ConfigureFromArgumentString
+ *
+ *
+ * @subsection alihltcomponent-initialization-sequence Initialization sequence
+ * Using the approach of <tt>TObjString</tt>-type configuration objects allows to treat
+ * configuration from both @ref DoInit and @ref Reconfigure in the same way.
+ *
+ * The base class provides the function ConfigureFromArgumentString() which loops over
+ * all arguments and calls the child's method ScanConfigurationArgument(). Here the
+ * actual treatment of the argument and its parameters needs to be implemented.
+ * ConfigureFromArgumentString() can treat both arrays of arguments and arguments in
+ * one single string separated by blanks. The two options can be mixed.
+ *
+ * A second bas class function ConfigureFromCDBTObjString() allows to configure
+ * directly from a number of OCDB objects. This requires the entries to be of
+ * type TObjString and the child implementation of ScanConfigurationArgument().
+ *