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 :
- MyStyles
- Style (database file)
- PagerDecoration
- Wharf folders
- 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.