Hi,
I'm working on updating some disgusting hack CGI scripts to use mod_perl and
DBI. The database backend is Informix, but the web structure is designed to
allow accessing different database configurations from different virtual
hosts. For example, http://dev:9040/ might be integrated with the main
working database, while http://dev:9041/ works with a testing or training
database. This separation is crucial in development and client use.
Unfortunately, Informix and one of our own libraries depends on environment
variables to distinguish this connection information (there is probably a
workaround for DBD::Informix but our library is bad painful legacy code with
awful and immutable API). Therefore, I need to set environment variables,
but the settings need to be somehow localized for each script.
The obvious solution is to put a bunch of assignments to $ENV{'blah'} at the
top of each script. This strikes me as rather ugly though, and forces our
developers to type more.
PerlSetEnv is almost a solution; its failing is that is doesn't fake scope
for environment variables (not that it should). If I could put PerlSetEnv
directives inside of <VirtualHost> or <Location> tags for Apache, and that
forced scoping upon them, that would be perfect.
Perhaps there is some way I can actually use reasonable Perl scoping to set
a variable in the scope of a Virtual Host? If so, then I could just specify
a hash of environment variables called %myEnv in each <VirtualHost> or
<Location> section, and the web scripts could just call a single function
like envImport(%myEnv) at the top. That would be great, as all
virtualHost-specific configuration would exist in Apache configuration
files.
The only other alternative I can think of is to store these settings in a
file and call a function to parse the local configuration file for each
script request. This seems to add a lot of overhead though. Files suck.
Any solutions from the mod_perl gurus out there?
Thanks,
Shimon Rura
CARS Information Systems, Cincinnati, OH
