Is there any way to take the Apache::ReadConfig name space
(variables set in <Perl> sections) and generate plain text
Apache directives?
For example, assuming some_function() returns "myhost", I would
like to convert the variables generated by:
<Perl>
$ServerName = some_function();
$Port = 80;
</Perl>
into:
ServerName myhost
Port 80
I have a hypothetical situation where a friend of a friend spent
a lot of time setting up a nice <Perl> configuration for an
extended family of web servers with various requirements. He
then realized that one of the requirements was that some of the
web servers run without mod_perl (to serve static files and proxy
requests to separate mod_perl servers).
My hypothetical friend of a friend is very embarrassed.
After studying the instructions given in the Eagle book on how
to convert plain directives into <Perl> variables, it seems that
it should be possible to traverse the name space in Apache::ReadConfig
and unwind the directives into something that standard mod_perl-less
Apache could process.
In fact, I have embarked on a project to build just such a tool.
Before I go too far, though, I thought it would be helpful to seek
wisdom here. Perhaps somebody else has already done this?
Perhaps mod_perl already has the code embedded in it that could
be used? Perhaps some wish to tell me it is near impossible in
the general case and I should abandon my foolish quest?
Of course, I realize that the output generated will not be able
to duplicate any side-effects or dynamic nature of code in the <Perl>
sections. One of the requirements for using this utility will be
that you only need the end results stored in Apache::ReadConfig.
I would be interested in suggestions for package naming if I do
succeed to an extent that others might be interested in using it.
Should I create a new method in the Apache::PerlSections name space
or would this be stepping on Doug's toes?
Please do let me know if anybody else has a use for such a tool.
This will help me figure out how much time I should spend trying to
handle the general cases instead of just writing it to meet my...
er, my friend's... specific needs.
Thanks
--
Eric Hammond
[EMAIL PROTECTED]
