Re: Proposed changes to configuration system

[Rick C. <ri...@pu...>]

     How about adding an option to specify an older-version
     config.php file to suck in settings from?  :)

     -Rick


> The first thing I noticed, trying to add a user-configurable
> feature, is how badly conf.pl needs to be rewritten.  Right now
> it's a
> 2000-line cludge with 95% or more of repetitive code, hard coded
> menus, and badly done regular expressions.
>
> Here are a few conceptual ideas that I'd like to implement:
>
> 1. Store option names, default values, and descriptions in a
> separate file, not necessarilly (even most likely not) directly
> parse-able by PHP.  Let's say config.ini.  For each option we
> also need to maintain the name of the category, where it appears.
>
> 2. config.php does not store any junk (like the comments), just
> the option names and the values.
>
> 3. When conf.pl is run, it
>   a. Reads in config.ini and stores the info in two hashes:
>      - %values, storing associations option -> value
>      - %descriptions, storing associations option -> textual
>        description
>   b. If config.php exists, conf.pl parses it, updating %values
>   hash
>      with the non-default values, if available.
>   c. The menus are generated dynamically from the information
>      obtained from config.ini.  (Right now all menus are
>      hard-coded).
>   d. Saving of options happens automatically by dumping the
>   %values
>      hash into config.php.  Original config.php is moved out of
>      the way.  If it contained any options that are no longer in
>      config.ini, they are out of the way now, too.
>
> This way, if a developer needs to add a config option, all he has
> to do is add a few lines to config.ini.
>
> Any comments?
> --
> Arcady Genkin
>
> --
> SquirrelMail Development Mailing List
> (http://www.squirrelmail.org)  Archives:
> http://www.squirrelmail.org/list_archives.php
> Unsubscribe:
> http://lists.sourceforge.net/lists/listinfo/squirrelmail-devel


-- 
ri...@pu...
http://rick.978.org/