Philippe M. Chiasson wrote: [...]
Philippe, has the allowed placement of <Perl> sections changed in mp2?
For now, <Perl> sections are still limited to server scope. I have a patch to open that up to OR_ALL (<Location> .htaccess and all) but I am not sure of exactly what behaviour a user would expect from a <Perl> section in a <Location > container. For example
<Location /foo> <Perl> $Global::SomeVar = 'foo'; </Perl> </Location>
<Location /bar> <Perl> $Global::SomeVar = 'bar'; </Perl> </Location>
Would certainly _not_ behave like people might expect. See what I mean ?
True. I suppose in mp1 it was just running them all at the server startup, having the latest value override the previous, isn't it?
So we should either keep it as it was in mp1, or make it DWIM. If we keep the mp1 behavior we ought to allow it everywhere, but document that it's not DWIM. How hard would it be to make it DWIM? I suppose one will need to stash code-refs into the dir/r struct and run them at request time, which won't work across threads, so the source will need to be stored. doesn't seem very effective to me. One is ought to use the PerlHeaderParserHandler to accomplish DWIM in the example above.
So I think it's the most sane to keep mp1's behavior. i.e.:
- allow <Perl> everywhere
- document that it's not DWIM (i.e. everythings is run at the server startup)
-- __________________________________________________________________ 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
