continuing from modperl@
In this thread you were trying to make PerlLoadModule do what it wasn't designed for.
that's an oversimplification and somewhat belittling.
PerlLoadModule does a few things:
- starts up an interpreter
That's a side effect, not the design goal.
- requires a module, thus running module init code - inserts code into the Apache module list (another oversimplification :)
to me, this all boils down to a module that requires init code to run during config time. in other words, directive handlers are merely a special case of what many modules want or require - code to be run at config time.
if we abstracted out that last point and offered an interface into modperl_module_add() this would be exactly like all the stuff I want to do. modules that used ap_register_provider() (the example I gave in the previous thread) and modperl_module_add() would both have the same requirements - they would need to be loaded using PerlLoadModule to ensure that their init code ran at config time.
so, my point is that PerlLoadModule is designed poorly - lots of modules would like to be able to take advantage of the first two points, with fewer taking advantage of the last. if the directive handler interface were a bit more generic then PerlLoadModule would have the effect I think it should, namely give modules a way to ensure that their init code is run at config time.
I guess that means that I'm also considering a redesign of the directive handler interface:
PerlLoadModule My::Module
where My::Module has:
use Apache::Module (); our @APACHE_MODULE_COMMANDS = (...); Apache::Module->add(__PACKAGE__);
or something similar. the added call really isn't all that much, as
directive handlers are still much, much simpler than they were in mp1.
If you do that, then it's the best to remove the magical @APACHE_MODULE_COMMANDS name, just pass an array as an argument? The special name is needed only when things happen behind the scenes.
the benefit is that PerlLoadModule is more of a LoadModule counterpart - not all C modules have directive declarations, you know :)
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?
And since you've mention this thread, it goes:
"BTW, one other reason for postponing startup is to be able to specify PerlSwitches anywhere in the config file and PerlInterp* directives as well (as Doug has reminded me). Something that won't work after perl was started."
So if you force an early startup, you can not use PerlSwitches and you better remove the whole feature, since it becomes useless.
mp1 has the same issue - use <Perl> sections before a PerlTaintCheck directive and the PerlTaintCheck directive is silently ignored (IIRC :). and PerlLoadModule as it exists currently has the same effect anyway. so really, this is an invalid argument as the situation exists already outside of wanting to change things around a but.
It's not invalid if you want to do more things than just set -Tw. Take a look at my reply to John:
<quote>
A more significant reason is that PerlSwitches must be set before perl starts. If you want to set PerlSwitches inside vhosts, and perl has already been started, you are out of luck. Here is why you want this feature:
http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlSwitches_ http://perl.apache.org/docs/2.0/user/config/config.html#C_Clone_ http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_
With a <perl> hack section, or a new directive to do just that - force the startup of the interpreter, you have a complete control over things. If we start early by default, then you're out of control.
</quote>
I fail to see how is that invalid.
So if you want to use some new directives in httpd.conf and set PerlSwitches at the same time, you really can't (even as it's now).
__________________________________________________________________ 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]
