AfterStep configuration Reading/Writing/Exchange issues

Problem

Many , many years ago, in the dark ages of Personal Computers and windowing interfaces there was AfterStep the Window Manager.
(joke)
In order to achive world dominance and ease of use goals Afterstep will need the following configuration related features :

GUI configuration tool (ASCP);
Dynamic configurability;
unifyed code for reading-writing configuration files;
comment friendly configuration file writing.

At the moment every AS module has it's custom code to read configuration from the plain text files. Such approach has advantage of simplicity. But it has also several disadvantages:

this code is usable only by this particular module, and needs to be reimplemented in ASCP, which is causing possible differences in the way ASCP and AS treating same options, slows down ASCP development;
in order to implement dynamic configurability this way - config will need to be written down into file - and file reread by module, which sucks.
as far as code is duplicated in many places bugs needs to be fixed everywhere instead of just one place. We've seen many things like that.
code like, base file processing is duplicated in any module.

Idea is to provide unifyed code that would be parsing configuration files, according to supplied structure, and would return values of different parameters. Also this should be capable of writing configuration files, without destroying comments if user wants to do so.

Solutions

Simple/nested constructs

In AfterStep configuration there are two different types of constructs :

Simple constructs - most afterstep options are simple constructs, and consists of pair <OptionName><parameters>
Nested constructs - some options :
1. MyStyles
2. Style (database file)
3. PagerDecoration
4. Wharf folders
5. autoexec file.
these options introduce structures that consists of several Simple constructs.

As the result configuration of any module and Afterstep overall can be represented by tree of configuration pairs <OptionName><parameters>, where any nested construct will be represented by additional branch.

Term

It is not a good idea to store OptionName in each configuration pair - there could be several option with the same name ( like *PagerStyle ), so storing this name in option would waste some memory. Besides it would be good to attach some information about how this option must be treated. That leads us to the consept of the Term.
Term is nothing but the structure that identifies configuration option and ways of it's processing. As logic dictates it contains the following data:

flags - flags identifying any special way of processing option. That could be combination of several flags. Flags could say for instance that option is indexed - which means that first parameter is index in array, in which following data should be inserted - for example PagerStyle, or that could be a flag indicating that option's parameters should not be split into space separated pieces, like for Wharf entries.
keyword - keyword identifying this option in config file.
type - data type of option's parameter. That allows for some standartized processing of data - for instance integer type would get first parameter converted into integer value.
id - unique identifyer of this option in the multitude of all available Afterstep options. That is useful in processing functions, so we don't have to check the keyword, to find out what option we are dealing with.

Syntax

Collection of Terms, that can be used in single module's config makes Syntax of this module's config.
Interesting thing here is that hwithin the configuration we can have like sub-configurations. For example in database file, each Style record is sub-configuration - and so is any nested construct. That means that it has a subset of terms.
That leads us to nessessity to supply more information to parsing code:

terminator - character that separates one option from another. Generally in Afterstep configuration that could be either '\n' character or ','.
file_terminator - character that terminates entire configuration file. That could be either '\0' - when end of file terminates file, or '\n' in case of some sub-configurations.

As the result we can define module's config can be defined as the combination of :

terms - array of term definitions;
terminator - character that separates options from one another;
terminator - character that terminates configuration file.

FreeStorage

This <OptionName><parameters> pair consept leads us to the definition of the FreeStorage. FreeStorage is a tree of all configuration pairs. Each configuration pair will become FreeStorageElem. This free storage elem should uniquely identify what Option it represents, and it will hold all parameters of this option.
Generaly option's parameters are nothing but space separated list of text items. That is not a rule indeed - some options, most notable wharf entries can consist of stuff that should not be separated - like command lines of applications to start.