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 - 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. the benefit is that PerlLoadModule is more of a LoadModule counterpart - not all C modules have directive declarations, you know :) > > 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. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
