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 :
  1. GUI configuration tool (ASCP);
  2. Dynamic configurability;
  3. unifyed code for reading-writing configuration files;
  4. 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:
  1. 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;
  2. in order to implement dynamic configurability this way - config will need to be written down into file - and file reread by module, which sucks.
  3. 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.
  4. 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 :
  1. Simple constructs - most afterstep options are simple constructs, and consists of pair <OptionName><parameters>
  2. 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:

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:
  1. terminator - character that separates one option from another. Generally in Afterstep configuration that could be either '\n' character or ','.
  2. 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 :

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.