What do you mean it has no clear utility, you've just heard John complaining on the users list that 'apachectl configtest' wasn't invoking mod_perl setup. Unless you think that suggesting to use the <perl> section hack is the best we can come up with.
actually, I think that his expectations are wrong. configtest is for making sure that the config is syntactically correct, that a TAKE1 directive has only one argument, etc. I don't really think that configtest was meant to catch things like invalid perl modules, even if it did in mp1. I don't think it catches things like invalid ErrorLog or RewriteLog paths or things of that nature either, which could also prevent the server from starting in real life, but I'm not sure.
Hmm, that's not a very nice policy, I'd suggest. 'configtest' is there to verify that once you do 'apachectl restart', your server will actually start. Apache can only go as far as running the config phase and expects the modules not to play tricks on it. Sure, the problem could be just as well in the child_init phase, but still it's nice to have mod_perl DWIM wrgt 'configtest' and not surprise people with production sites...
The only solution I could think of is to add a some hook into config that will check whether we are running under configtest and will force the perl startup at the end of config if it's not running already. These new query status thingies added in 2.0.49 (?) for the starting/restarting may need to be extended to tell us when a 'configtest' is running.
that's not a bad idea and would be a nice bonus.
Yeah, but I'm not going to do any digging into httpd any time soon. I really want to get the API finalizing going at full speed, as a first priority. So if you get a chance to look at it, that would be great.
I had thought about creating some kind of flag (local %ENV or package variable) that would act as a flag in those circumstances. so a module could
die unless $Apache::Module::IsPerlLoadModule;
or something. I admit, it's a stretch, but some mechanism would be nice.
that's wacky. That's why we may need to change the name of that directive, so there will be no confusion.
the name of the directive may not have any bearing on this, since there would always be the danger of both being used to load modules. PerlModule and PerlRequire are pretty much the same, but it's only by convention that we use one over the other. this would be a convention as well.
Not quite so. PerlModule == use, PerlRequire == require. So they map 1:1 to the familiar perl functions. So if can come up with a better non-ambiguous naming for this new directive that's the best. Doug, who came up with that name, had put 'XXX: not sure if that's going to stay' and I think I've removed that XXX some time go.
I hope we aren't going to piss off too many folks with these late changes...
I highly doubt that people are using directive handlers in mp2 yet. almost nobody used them in mp1 so they're still a pretty obscure feature. I seem to be the exception on both fronts :)
I know, I was talking in general (e.g. me going to completely change the socket IO API), and probably more to come in the next few weeks, as I'm going to try and make a consistent *perlish* api, and use the C'ish API only when it's really needed, or we have a similar function in perl which is not quite perlish (e.g. read()/sysread() which put the data into the argument)
besides, the point of not having a 2.0 release yet is so we can create the best stable API we can ;) seriously, without doing something in this area, lots of mp1 people will be without a feature they used to rely on short of sticking in <Perl> sections.
Sure. __________________________________________________________________ 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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
