Hi Colin,
just my opinion, but from a 'practicalities' point of view, as startup.pl gets more complex (your site grows larger, you wish to do more intricate mod_perly things), you will find that it is a distinct advantage to run it from the command line in the debugger. you wouldn't be able to do this if you buried all your perl in the apache configs...
Actually as philippe reminds me you can enclose the Apache stuff in =pod stuff
=pod This is some pod data =over apache PerlSetVar TestDirective__pod_over_worked yes =back This is some more pod =cut PerlSetVar TestDirective__pod_cut_worked yes
so you can run:
perl -c httpd.conf
I'm sure there's many more reasons to keep your startup script outside of the http configs, usually it's because it's only neat and tidy to begin with embedding your perl into your configs, but as your site configs get larger, you'll probably start thinking it a better idea to put all your <perl> sections in their own seperate httpd conf file, which might as well be a startup.perl script......
that's correct. <Perl> sections are really there only for doing Apache config and nothing else. It just so happens that people "mis-use" the feature.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
