Config parsing module for mod

jehuni has asked for the wisdom of the Perl Monks concerning the following question:

I'm looking for a lightweight config parsing module to use in a mod_perl application. The obvious answer seems to be: just use PerlSetVar directives inside of Apache's own config file(s). However, I'd like to keep configuration information that's not mod_perl specific (for example, things like database connection parameters) out of the Apache config files. I'd like this info to be available to a startup script called from httpd.conf, as well as available outside of Directory or Location sections, but PerlSetVar info is normally only accessible inside a request (I think). Also, I'd ideally like to be able to update my config files and have them reparsed without having to restart Apache.

First of all, feel free to tell me that the above approach is a bad one and that I should stick with Apache's own config parsing features. But, if not, read on ...

I have some hand-rolled code that I'm using at the moment. It involves a globally available tied hash that caches the config parameters, then stats the config file each time a parameter is fetched. If the config file's modification time has changed, it reparses the file; otherwise it uses the cache. However, I'd prefer to use a module from CPAN for all the usual reasons. I've browsed through CPAN, as well as Super Searched here on perlmonks, and there are plenty of modules that will do the config parsing with no problems. However, since I haven't used any of these modules in a production environment, here's what I'm ultimately looking for in a module:

It parses standard types of config files. (OK, this is obvious, but I thought I'd restate it.)
It reparses config files if they have changed. Otherwise, the config info should stay cached.
It has a small memory footprint. Since this is running under mod_perl, it will stay in memory for the life of the process.

It would be nice to use AppConfig, since I'm already using Template Toolkit, meaning that AppConfig is already installed. However, I'm not familiar with it enough to know about its memory requirements and ability to reparse changed files. Again, there are plenty of others which meet the first requirement, but I'm not sure about the other two.

Any suggestions?

-jehuni

Comment on Config parsing module for mod_perl app?

Replies are listed 'Best First'.
(jeffa) Re: Config parsing module for mod_perl app? by jeffa (Bishop) on Mar 27, 2002 at 14:42 UTC
maverick is currently developing a mod_perl application developement kit that covers many of your quetions. It does use HTML::Template instead of Template Toolkit, however, but it does have the ability to 'pick up' changes to a module without having to restart the web server. Also used is Config::General, which reads configuration files that describe which modules to load and also provide rules for which module(s) handle which page(s). Since i am merely documenting this project, i don't really know the details involved in how maverick achieved the results you are looking for (not having to restart the web server and a light footprint), but i can tell you that it is possible - the hard part is detecting new methods or removed methods. He recommends checking out Apache::StatINC and Apache::Reload. ~~Good luck, and we will announce the release of Voodoo, hopefully, very very very soon. ;) Oh what the heck, everybody and anybody who is interested /msg me and i will keep you posted.~~ UPDATE: After having used this code for some time, i have determined that it really is only useful if your name is maverick. Set up is just too much of a PITA (and differs from box to box) to be considered commercial. I am looking for other solutions at this point. jeffa L-LL-L--L-LL-L--L-LL-L-- -R--R-RR-R--R-RR-R--R-RR B--B--B--B--B--B--B--B-- H---H---H---H---H---H--- (the triplet paradiddle with high-hat)	[reply]
Re: Config parsing module for mod_perl app? by perrin (Chancellor) on Mar 27, 2002 at 15:09 UTC
First, what you're doing now sounds fine. I don't see why it needs to be a tied hash rather than a normal one, but the concept is fine. If you do want to switch to something new, don't bother looking for a config parser that will watch for changes: there are none. Find one that supports a syntax you like, and then add the mod_perl specific stuff yourself. All you need to do is put in a cleanup handler that will stat the config file and then call your config parser again if it changes. You can keep track of the last time you read it in a global variable. If you don't want to stat every time, you can keep track of the last time you did a stat, and only stat again if it's five minutes later.	[reply]
Re: Config parsing module for mod_perl app? by jehuni (Pilgrim) on Mar 27, 2002 at 18:42 UTC
I assume that you suggest a cleanup handler since it runs after a request, so the user sees no performance hit, but correct me if I'm wrong, please. And the reason that I'm in favor of moving to a CPAN module was an attempt to make the code more modular and maintainable. (And, yes, my use of a tied hash is probably unnecessary. :-) (While mulling this over, I thought of the following idea, but maybe it's overkill. Use Apache::Reload with PerlSetVar ReloadAll Off. Then, use PerlSetVar ReloadModules to explicitly register my config-reading module. However, then I PerlSetVar ReloadTouchFile to the name of the config file. That should have the effect of only reloading my config-reading module whenever the touch file changes, and since the touch file will be the config file itself, that should have the desired effect.) So, anyway, I've got some good ideas to work with. Thanks to those who replied. I'm still left with one question, though: what's the lightest weight yet reliable config-parsing module out there? And one that properly handles file locking in case of multiple concurrent requests, as well? -jehuni	[reply]
Re: Re: Config parsing module for mod_perl app? by perrin (Chancellor) on Mar 27, 2002 at 19:10 UTC
Yes, right about the cleanup handler. Your Apache::Reload idea sounds fine, but the code to stat a file and run your config parser again is awfully simple so don't be afraid to just write it. I don't think there's much difference between the config modules in terms of reliability (it's a fairly simple task), but for determining memory footprint I think you will just have to load them into memory to see. Larger files usually lead to more memory, unless the file is mostly POD. Don't worry about file locking. When you want to update your config file, just do it with a rename, i.e. `mv myconfig.conf.new myconfig.conf`. That should be an atomic update.	[reply] [d/l]
Re: Config parsing module for mod_perl app? by Stegalex (Chaplain) on Mar 27, 2002 at 14:35 UTC
It may be heresy to say here but I have enjoyed using Config::IniFiles which allows you to use Windoze-style initialization files. I like chicken.	[reply]
Re: Config parsing module for mod_perl app? by trs80 (Priest) on Mar 28, 2002 at 06:47 UTC
I use XML::Simple to convert my configuration files to a hash from XML, this allows me multiple ways to access and deal with the information outside of Perl if needed.	[reply]