> That's exactly what will happen if a user will use PerlModule instead of > PerlLoadModule at the moment. It'll silently fail.
yes. but in some circumstances the failure might not be silent - directive handlers would fail because httpd would croak, for example. but you're right, there is a danger. > 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?). well, something about that strikes me as dangerous. PerlStartNow has no clear utility. that is, everyone knows what <Perl> sections do, and hopefully we could explain that PerlLoadModule would be for modules that need to run init code. but PerlStartNow is kind of floating in the aether - starting the interpreter on demand has no clear benefit or activity associated with it. > 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. that's true, except that we can document it in terms of using it for modules that need to interact with config-time activities, such as loading directives into the server before other modules (like mod_authn_basic) get the chance to start. > And you can't really ensure that a user won't > invoke your module via PerlModule. 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. > Sure. I don't think we have any remaining disagreements here. whew! :) ok, I'll start working up a patch that will take directive handlers to the next level. keep the ideas coming and we'll get something together that's spiffy :) --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
