perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: a new directive: PerlStartupFile?
Date Sat, 11 Dec 2004 03:50:26 GMT
Philippe M. Chiasson wrote:
> Stas Bekman wrote:
> 
>> OK, the post_config story is now resolved, we can get back to this 
>> discussion.
>>
>> Larry Leszczynski wrote:
>>
>>> Hi Stas -
>>>
>>>> As a followup to the discussed issue, we need to redefine the 
>>>> concept of:
>>>>
>>>>   "put those things in startup.pl"
>>>>
>>>> we now need to say:
>>>>
>>>>    "put those things in post_config phase handler"
>>>
>>>
>>> [...]
>>>
>>>> So there is a possibility to introduce a new directive: PerlStartupFile
>>>> (feel free to suggest a better name) which will be:
>>>>
>>>> PerlStartupFile "somefile.pl"
>>>
>>>
>>> [...]
>>>
>>>> after discussing this with gozer on irc we aren't sure this is a good
>>>> idea, as for most people using the old startup.pl concept will still 
>>>> work.
>>>
>>>
>>> Leaving things as-is sounds like it might be asking for trouble, e.g.
>>> people not aware of the implications between config and post-config, or
>>> people still using "PerlRequire startup.pl" from their mp1 setup and it
>>> works ok by coincidence, and suddenly stops working (or fails in
>>> mysterious ways) when they add something that unknowingly breaks the 
>>> rules
>>> about config vs. post-config phases.
>>
>>
>> Everything will work just the same either way, it's just that STDERR 
>> is closed during the config phase's 2nd pass (when Apache restarts 
>> itself).
> 
> 
> And also, most people will not be doing things that are 'forbidden' in 
> there,
> like running different code on each pass, so it should be harmless in most
> cases.
> 
>>> Maybe it would also help to introduce an alias for PerlRequire called
>>> something like PerlConfigFile, to make it more obvious it should only be
>>> used to modify config, and recommend that instead of using "PerlRequire
>>> startup.pl" people should do:
>>>
>>>    PerlConfigFile  "some-file.pl"
>>>    PerlStartupFile "some-other-file.pl"
>>>
>>> Or maybe since there is already PerlPostConfigHandler, parallel that and
>>> use the name PerlPostConfigFile instead of PerlStartupFile?:
>>>
>>>    PerlConfigFile     "some-file.pl"
>>>    PerlPostConfigFile "some-other-file.pl"
> 
> 
> I like the consistency in this case.
> 
>>> (Don't know about that, maybe PerlStartupFile seems more intuitive about
>>> what you'd use it for...)
>>
>>
>> Yup, those are the two ideas philippe and I have discussed, we are 
>> just not sure it's a very good idea to introduce a new directive which 
>> does the same thing as PerlRequire. But in fact I like the idea. Since 
>> PerlRequire normally is not run during the config phase (unless 
>> something forces perl startup early, e.g. perlloadmodule or <perl> 
>> section). So currently:
>>
>>   PerlRequire "startup.pl"
>>
>> doesn't necessarily runs during the config phase.
>>
>> by making PerlConfigFile forcing perl startup early, it'll make more 
>> sense, since it'll ensure to be run during the config phase.
> 
> 
> Yes. less magic and more consistency. I think it does make sense.
> 
>> and then of course PerlPostConfigFile which does the wrapping to push 
>> the handler is a nice sugar syntax.
>>
>> So I'm +1 for:
>>
>>     PerlConfigFile     "some-file.pl"
>>     PerlPostConfigFile "some-other-file.pl"
> 
> 
> I think it's a good choice as well, but what about PerlRequire itself ? 
> Just an
> alias to PerlConfigFile ?

PerlRequire stays where it is.

PerlConfigFile = StartPerl + PerlRequire (ensures to be run at config phase)

Same as PerlLoadModule vs. PerlModule.



-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message