Return-Path: 
 <dev-return-4533-apmail-perl-dev-archive=perl.apache.org@perl.apache.org>
Delivered-To: apmail-perl-dev-archive@perl.apache.org
Received: (qmail 29143 invoked by uid 500); 22 May 2003 13:28:14 -0000
Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@perl.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@perl.apache.org>
list-post: <mailto:dev@perl.apache.org>
Delivered-To: mailing list dev@perl.apache.org
Received: (qmail 29094 invoked from network); 22 May 2003 13:28:13 -0000
Received: from unknown (HELO secure.exclamationlabs.net) (66.77.29.176)
  by daedalus.apache.org with SMTP; 22 May 2003 13:28:13 -0000
Received: from modperlcookbook.org (ham-nat.covad.net [68.165.151.221])
	(authenticated (0 bits))
	by secure.exclamationlabs.net (8.11.6/8.11.6) with ESMTP id h4MDSD401774;
	Thu, 22 May 2003 08:28:13 -0500
Message-ID: <3ECCD069.6020302@modperlcookbook.org>
Date: Thu, 22 May 2003 09:28:09 -0400
From: Geoffrey Young <geoff@modperlcookbook.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Stas Bekman <stas@stason.org>
CC: dev@perl.apache.org
Subject: Re: removing PerlLoadModule directive handler requirement
References: <3ECA2E68.1080205@modperlcookbook.org>
 <3ECABF44.6020503@stason.org> <3ECAE147.40206@modperlcookbook.org>
 <3ECAE5DD.3000901@stason.org> <3ECB6EBA.7020409@modperlcookbook.org>
 <3ECC3A60.8060206@stason.org> <3ECC4BC8.4090609@modperlcookbook.org>
 <3ECC4F41.3040604@stason.org> <3ECC541A.9030000@modperlcookbook.org>
 <3ECC59F3.2010200@stason.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


 >> not exactly.  I think it's fine in most cases to have PerlModule behave
 >> as it does now.  it's in the exceptional cases that the problem
 >> resides.
 >
 >
 > Actually it's not fine now. Consider:

 > PerlRequire /path/to/startup.pl
 >
 > As the current implementation goes we have a problem, because it won't
 > work unless something (<Perl> or PerlLoadModule) has triggered a perl
 > startup and the startup.pl file was actually required during the config
 > phase.

oops :)

 >
 > So what I'm saying that your issue is not the only one that requires an
 > early perl startup. So may be the problem is more global and solving it
 > will automatically resolve your issue, without any heavy patching.

as I had originally though about it, I figured the issue would only reside
with modules.  but, as you pointed out, config changes in startup.pl will 
have issues too.  hmph.

personally, I can't see many people using add_config from a startup.pl - if 
they can add a startup.pl they can add the config themselves (except for 
maybe the tests :).  more typically, I would expect add_config() to be 
called from modules as to add config settings silently.  Apache::WinBitHack 
is a good example - it overrides XBitHack but (in mp1) still needs to add a 
PerlFixupHandler to function properly.  in mp2 it would just override 
XBitHack and silently add the fixup handler via add_config().  doug's 
illustration of using it to add require directives I suspect will also be a 
common use.

are there other config situations other than add_config() that you can think 
of?  I still think it's valid to delay interpreter start and have PerlModule 
behave as it does now (provided we have an alternative :), but as the number 
of exceptional cases rise, it makes less and less sense.

--Geoff


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