In which case why having two directives, if they do the same thing? Drop PerlLoadModule completely and have a new directive that will start the interpreter on demand, add the new API to Apache::Module. Won't that solve the problem?
not really. the issue that started this discussion aside, if I have a module that implements directive handlers I would need two directives instead of one. for the new issue (module init code) the code simply wouldn't run if the interpreter weren't started, possibly failing silently.
That's exactly what will happen if a user will use PerlModule instead of PerlLoadModule at the moment. It'll silently fail. Meaning that you need to document that one needs to do:
PerlLoadModule Foo
which is just as well, could be documented as:
PerlStartNow PerlModule Foo
especially if we are going to add PerlStartNow anyway (are we?). But I don't have any hard preferences. All I was saying is that if you remove the magickness of PerlLoadModule with regards to add_module, then the only remaining difference between PerlModule and PerlLoadModule is that the latter starts perl. And you can't really ensure that a user won't invoke your module via PerlModule.
really, I think we're looking at the whole issue differently. I want code to run during config. this happens to require an interpreter. you keep focusing on starting the interpreter early or "on demand" which I think is the wrong way to look at it. again, it's not early if I require it, which directive handlers (and other things) currently do.
Sure, if you want it that way then be it.
It's not invalid if you want to do more things than just set -Tw. Take a look at my reply to John:
I fail to see how is that invalid.
I understand the issues. but if you're saying that giving me an interpreter before you're ready invalidates things like PerlSwitches, I was merely pointing out that the ability exists already, so it's not like I'm asking for something that mucks up existing strategies. the muck exists and is possible already with the existing directive structure.
Sure. I don't think we have any remaining disagreements here.
__________________________________________________________________ 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]
