I've recently uncovered a bug in the config handling of OpenGuides. Sometimes default config values are set inside the script, but inconsistently (and multiple times). This causes problems when the config file is missing an item. In my opinion all software should gracefully handle missing configuration items as much as possible, but at the same time having to set the same default in the code itself (for example, geo_handler is set and defaulted three times in the code) is bad.
I suspect the best way to solve this would be something along the lines of a getconf method in OpenGuides::Utils which would look like Config::Tiny, but with hardcoded defaults built in. This would solve the problem of inconsistent defaults, and also abstract away the details of where the config comes from, should we want to expand the possiblities in future (eg reading config from a database, a different Config::Foo module, etc).
Another immediate application for this is the possibility of a global config, as discussed in http://openguides.org/mail/openguides-dev/2003-September/000043.html. In fact the patch in that mail does provide something quite similar, but I think not relying on another external config file being findable would be best (though supporting it would be good), and I think that patch tries to be too clever (and makes assumptions about file locations).
We basically want to be able to do
my $config = OpenGuides::Utils->getconf;
once and then not care any more.
We should also have a definition of what should be considered a required value, because of course some variables do not have a sensible default at all. Something like:
# Default configuration definitions my %defaults = (dbname => undef, dbuser => undef, dbpass => undef, dbhost => "localhost", script_url => "http://localhost/cgi-bin/wiki.cgi", use_plucene => 1, indexing_directory => undef, enable_page_deletion => 0, admin_pass => "Change This!", stylesheet_url => undef, site_name => "Unconfigured OpenGuides site", navbar_on_home_page => 1, home_name => "Home", site_desc => "A default configuration of OpenGuides", default_city => "London", default_country => "United Kingdom", default_language => "en", contact_email => "openguides-admin@example.com", formatting_rules_node => "Text Formatting Examples", backlinks_in_title => 0, geo_handler => 1, ellipsoid => "International");
To preempt the possible question "Why do this? The Build script always adds in all the require values": the answer is that software should be robust, and we need to cope with people willy-nilly hacking around with the config files. This includes people who want to build distributions of OpenGuides such as me for Debian. In that context the Build script is not the best way of managing things. By contrast, hard-coded defaults is Utils.pm can be considered immutable.
Also, of course, this hardcoding of defaults is already been done, and badly. It would make the code more understandable and less prone to error to be able to look in one place to discover the default behaviour of the code.
What do people think of this idea? Would someone like to step up and implement it? If the answer is yes, and rt.cpan.org comes back up, I'll submit it as a wishlist bug.
Cheers,
Dominic.