Re: [Openinteract-dev] example of new server.ini @INCLUDE syntax

[Salve J N. <sal...@me...>]

Some thoughts...

Chris Winters wrote:
> Since I didn't get much of a response from my previous inquiry about a
> possible change to the server configuration files I've created an example:
> 
>   http://www.openinteract.org/new_config_example/
> 
> The example uses the live configuration from my website (with passwords
> and such changed of course) and shows the full configuration vs. what it
> would look like broken down into files. It's all the same data. The main
> configuration contains the data users are most likely to change (database,
> session, email server + addresses, deployment context) and that's it.
> 
> See what you think.

Given the possibility that the amount of configuration entries
(sections, key/value pairs) become large enough, you might want to
consider complexity of "depth" (lots of info at few places - a "deep"
configuration tree structure) vs. complexity of breadth (lots of places
with just a little info everywhere - a "shallow" or "flat" config tree.)

Proximity of configuration entries (wether two unrelated entries can be
found in the same file, directory or even filesystem) should be part of
your consideration. Obviously, keeping all configuration close together
has some benefits (searchability, easy access) but too much in one place
can increase the learning curve and/or make comprehension more difficult.

This is roughly the same problem as "having too much documentation" vs.
"having too little documentation easily available"

I think the sweet spot most likely lays somewhere in-between the two,
and that the clue to make this information accessible (easy to
find/scan, read, understand) lays with good (sensible, intuitive,
natural, conventions/standards-abiding) abstractions and categorization
of the information, and to keep the "depth" at a minimum while still
staying within a "width" that is comprehensible for the casual observer.

Given this, I'd make the following suggestions:

  * Reduce the amount of configuration files, if possible.
  * Group related config sections more tightly together (e.g. put the
"main" datasource together with the other datasources.)
  * KISS. Is it necessary to differentiate between Controllers and
Content Generators? (Perhaps a different issue, but maybe worthwhile to
look into if your're trying to clean up configuration anyway. Reducing
the amount of necessary concepts to learn helps both with file size and
understandability. :)
  * Package-related config should be placed somewhere very close, but
seperatly from the server config (e.g. the "fulltext" package config has
IMHO nothing to do in the conf/server.ini file, and the base_user
action.ini files are too far away in pkg/base_user/conf.) I'd like to
suggest that all package config files are accessible from a suitable
"package.d" directory (e.g. "conf/packages.d/fulltext.ini"), and that
the main config file @INCLUDEs these en-masse. The conf/packages.d/*.ini
files need not to be more than symlinks to the packages in order to get
a positive effect.
  * When upgrading some software (OI2 or .zip packages,) I'd like to
keep my old config, but still get the new features. Splitting up files
(as you described) may help with this, so do place commonly changed
config entries in one or more seperate files.
  * BTW, I'd like to keep my timezone when I upgrade the server. :)
  * s/server_action_info.ini/server_actions.ini/g (Naming consistency is
good. :)
  * The ini file parser should warn about inconsistencies and duplicate
entries if they're not allowed.
  * Configuration entries that have related entries that for some
greater reason can't be placed "close by", should at least reference the
related entries.

Just my USD 0.02. Feel free to criticise! :)


- Salve

-- 
Salve J. Nilsen <salvejn at met dot no> / Systems Developer
Norwegian Meteorological Institute           http://met.no/
Information Technology Department / Section for Development