in reply to Re: How do you load configuration variables
in thread How do you load configuration variables

I always create a module to handle program configuration, and I always call it Program::RC

Then Program::RC has a method new that instantiates an object that reads the configuration from whereever it is stored (config file, la windows INI file is pretty good, with permissions well set so as to protect sensitive data), database, LDAP directory, whatever.

The class offers a series of methods to access the different parts of the configuration file and give the variables values.

This approach has one added advantage, each time you instantiate a configuration object, the config file is read, so you can change the configuration and test it on the fly, not even a SIGHUP is needed.

An example:

use Foo::RC; # prepare things ... # now fork if ( my $pid = fork() ) { my $ret = process_request( @ data ); # ... other hooks, or whatever } else { ... } sub process_request { # blah blah blah my $rc = new Foo::RC; my ($server_ip, $server_port, $bind_dn, $bind_passwd) = $rc->get_ldap_server_data; # ... }

Each time the program has to process a request, it reads its configuration. Unless it's a huge config file, this is almost unnoticeable delay, and you can always memoize or create a cache for this system once it's production time (this is really useful to developing/debugging...)

good luck,

NB: as I usually use Net::Server to make these things, the fork code can be wrong, please forgive me...

our $Perl6 is Fantastic;

Replies are listed 'Best First'.
Re: Re: Re: How do you load configuration variables
by sauoq (Abbot) on Jul 14, 2003 at 06:17 UTC
    I always create a module to handle program configuration, and I always call it Program::RC

    Why not just write that module once, name it once, and then reuse it in each application? Better yet, why not just use a module that already exists for just such a purpose; something like AppConfig, for instance?

    No matter how you access your config file — AppConfig, a home-brewed module, do $config or die $!, whatever — it's still best to hardcode the path in your program and allow it to be overridden with command-line args or envariables as necessary.

    "My two cents aren't worth a dime.";

      Hi there,

      It's a good question, and it deserves a good answer: I cannot always choose my config files format. So my Foo::RC will create an abstraction layer on top of the config file.

      Another goo reason is that this way I create the interfaces I like (which I would have anyway to write better code, eg.:

      my $rc = new Foo:RC; my $ldap = Net::LDAP->new( $rc->ldap_data ); $ldap->bind( $rc->ldap_bind_data ) or die $@;

      Among a wide amount of possible situations.

      Granted, Foo::RC would use AppConfig or any other of the configuration modules available in CPAN. But when you have to read INI files, normal /etc/* kind of config files (hence calling the module RC), XML config files or config data stored in a LDAP directory, Foo::RC makes a lot of sense and life much more easier...

      Best regards,

      our $Perl6 is Fantastic;