Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Re: How do you load configuration variables

by Excalibor (Pilgrim)
on Jul 13, 2003 at 22:14 UTC ( [id://273838]=note: print w/replies, xml ) Need Help??


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.

    -sauoq
    "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;

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://273838]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (2)
As of 2024-03-19 04:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found