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\(a)example.com".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.