Quest in configuration file

After almost a year of wondering I finally discovered what does this mean in sphinx4 config files:

<component name="activeListManager"
type="edu.cmu.sphinx.decoder.search.SimpleActiveListManager">
<propertylist name="activeListFactories">
<item>standardActiveListFactory</item>
<item>wordActiveListFactory</item>
<item>wordActiveListFactory</item>
<item>standardActiveListFactory</item>
<item>standardActiveListFactory</item>
<item>standardActiveListFactory</item>
</propertylist>
</component>

Actually it's even described in docs:

The SimpleActiveListManager is of class edu.cmu.sphinx.decoder.search.SimpleActiveListManager. Since te word-pruning search manager performs pruning on different search state types separately, we need a different active list for each state type. Therefore, you see different active list factories being listed in the SimpleActiveListManager, one for each type. So how do we know which active list factory is for which state type? It depends on the 'search order' as returned by the search graph (which in this case is generated by the LexTreeLinguist). The search state order and active list factory used here are:

State TypeActiveListFactory
LexTreeNonEmittingHMMStatestandardActiveListFactory
LexTreeWordStatewordActiveListFactory
LexTreeEndWordStatewordActiveListFactory
LexTreeEndUnitStatestandardActiveListFactory
LexTreeUnitStatestandardActiveListFactory
LexTreeHMMStatestandardActiveListFactory

There are two types of active list factories used here, the standard and the word. If you look at the 'frequently tuned properties' above, you will find that the word active list has a much smaller beam size than the standard active list. The beam size for the word active list is set by 'absoluteWordBeamWidth' and 'relativeWordBeamWidth', while the beam size for the standard active list is set by 'absoluteBeamWidth' and 'relativeBeamWidth'. The SimpleActiveListManager allows us to control the beam size of different types of states.

It's hard to guess, isn't it? Well, I hope soon we'll be able to make configuration easier. The idea of annotatated configuration came to my mind today. With the older idea of using task-oriented predefined configurations it could really save a lot of efforts.