Stas Bekman wrote: > Geoffrey Young wrote: > >> 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.
no, it's a requirement for directive handlers which are XS free. >> 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. great idea. cool. > >> 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? 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. 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. > 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. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
