PerlModule versus PerlLoadModule

[Geoffrey Young <ge...@modperlcookbook.org>]

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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: PerlModule versus PerlLoadModule

[Stas Bekman <st...@stason.org>]

Geoffrey Young wrote:
>>What do you mean it has no clear utility, you've just heard John
>>complaining on the users list that 'apachectl configtest' wasn't
>>invoking mod_perl setup. Unless you think that suggesting to use the
>><perl> section hack is the best we can come up with.
> 
> 
> actually, I think that his expectations are wrong.  configtest is for making
> sure that the config is syntactically correct, that a TAKE1 directive has
> only one argument, etc.  I don't really think that configtest was meant to
> catch things like invalid perl modules, even if it did in mp1.  I don't
> think it catches things like invalid ErrorLog or RewriteLog paths or things
> of that nature either, which could also prevent the server from starting in
> real life, but I'm not sure.

Hmm, that's not a very nice policy, I'd suggest. 'configtest' is there to 
verify that once you do 'apachectl restart', your server will actually start. 
Apache can only go as far as running the config phase and expects the modules 
not to play tricks on it. Sure, the problem could be just as well in the 
child_init phase, but still it's nice to have mod_perl DWIM wrgt 'configtest' 
and not surprise people with production sites...

>>The only solution I could think of is to add a some hook into config
>>that will check whether we are running under configtest and will force
>>the perl startup at the end of config if it's not running already. These
>>new query status thingies added in 2.0.49 (?) for the
>>starting/restarting may need to be extended to tell us when a
>>'configtest' is running.
> 
> 
> that's not a bad idea and would be a nice bonus.

Yeah, but I'm not going to do any digging into httpd any time soon. I really 
want to get the API finalizing going at full speed, as a first priority. So if 
you get a chance to look at it, that would be great.

>>>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.
>>
>>
>>that's wacky. That's why we may need to change the name of that
>>directive, so there will be no confusion.
> 
> 
> the name of the directive may not have any bearing on this, since there
> would always be the danger of both being used to load modules.  PerlModule
> and PerlRequire are pretty much the same, but it's only by convention that
> we use one over the other.  this would be a convention as well.

Not quite so. PerlModule == use, PerlRequire == require. So they map 1:1 to 
the familiar perl functions. So if can come up with a better non-ambiguous 
naming for this new directive that's the best. Doug, who came up with that 
name, had put 'XXX: not sure if that's going to stay' and I think I've removed 
that XXX some time go.

>>I hope we aren't going to piss off too many folks with these late
>>changes...
> 
> 
> I highly doubt that people are using directive handlers in mp2 yet.  almost
> nobody used them in mp1 so they're still a pretty obscure feature.  I seem
> to be the exception on both fronts :)

I know, I was talking in general (e.g. me going to completely change the 
socket IO API), and probably more to come in the next few weeks, as I'm going 
to try and make a consistent *perlish* api, and use the C'ish API only when 
it's really needed, or we have a similar function in perl which is not quite 
perlish (e.g. read()/sysread() which put the data into the argument)

> besides, the point of not having a 2.0 release yet is so we can create the
> best stable API we can ;)  seriously, without doing something in this area,
> lots of mp1 people will be without a feature they used to rely on short of
> sticking in <Perl> sections.

Sure.
__________________________________________________________________
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

Re: PerlModule versus PerlLoadModule

[Geoffrey Young <ge...@modperlcookbook.org>]

> What do you mean it has no clear utility, you've just heard John
> complaining on the users list that 'apachectl configtest' wasn't
> invoking mod_perl setup. Unless you think that suggesting to use the
> <perl> section hack is the best we can come up with.

actually, I think that his expectations are wrong.  configtest is for making
sure that the config is syntactically correct, that a TAKE1 directive has
only one argument, etc.  I don't really think that configtest was meant to
catch things like invalid perl modules, even if it did in mp1.  I don't
think it catches things like invalid ErrorLog or RewriteLog paths or things
of that nature either, which could also prevent the server from starting in
real life, but I'm not sure.

> 
> The only solution I could think of is to add a some hook into config
> that will check whether we are running under configtest and will force
> the perl startup at the end of config if it's not running already. These
> new query status thingies added in 2.0.49 (?) for the
> starting/restarting may need to be extended to tell us when a
> 'configtest' is running.

that's not a bad idea and would be a nice bonus.

>> 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.
> 
> 
> that's wacky. That's why we may need to change the name of that
> directive, so there will be no confusion.

the name of the directive may not have any bearing on this, since there
would always be the danger of both being used to load modules.  PerlModule
and PerlRequire are pretty much the same, but it's only by convention that
we use one over the other.  this would be a convention as well.

> I hope we aren't going to piss off too many folks with these late
> changes...

I highly doubt that people are using directive handlers in mp2 yet.  almost
nobody used them in mp1 so they're still a pretty obscure feature.  I seem
to be the exception on both fronts :)

besides, the point of not having a 2.0 release yet is so we can create the
best stable API we can ;)  seriously, without doing something in this area,
lots of mp1 people will be without a feature they used to rely on short of
sticking in <Perl> sections.

--Geoff

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

Re: PerlModule versus PerlLoadModule

[Stas Bekman <st...@stason.org>]

Geoffrey Young wrote:
[...]
>>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.

What do you mean it has no clear utility, you've just heard John complaining 
on the users list that 'apachectl configtest' wasn't invoking mod_perl setup. 
Unless you think that suggesting to use the <perl> section hack is the best we 
can come up with.

The only solution I could think of is to add a some hook into config that will 
check whether we are running under configtest and will force the perl startup 
at the end of config if it's not running already. These new query status 
thingies added in 2.0.49 (?) for the starting/restarting may need to be 
extended to tell us when a 'configtest' is running.

>>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.

I guess so. In which case the mnemonics of this directive's name are now not 
as clear.

>>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.

that's wacky. That's why we may need to change the name of that directive, so 
there will be no confusion.

>>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 :)

I hope we aren't going to piss off too many folks with these late changes...

__________________________________________________________________
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

Re: PerlModule versus PerlLoadModule

[Geoffrey Young <ge...@modperlcookbook.org>]

> 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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: PerlModule versus PerlLoadModule

[Stas Bekman <st...@stason.org>]

Geoffrey Young wrote:

>>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.

That's exactly what will happen if a user will use PerlModule instead of 
PerlLoadModule at the moment. It'll silently fail. 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?). 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. And you can't really ensure that a user won't invoke your module 
via PerlModule.

> 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.

Sure, if you want it that way then be it.

>>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.

Sure. I don't think we have any remaining disagreements here.

__________________________________________________________________
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

Re: PerlModule versus PerlLoadModule

[Geoffrey Young <ge...@modperlcookbook.org>]

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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Re: PerlModule versus PerlLoadModule

[Stas Bekman <st...@stason.org>]

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.

>   - 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.  

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.

> 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?

>>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.

It's not invalid if you want to do more things than just set -Tw. Take a look 
at my reply to John:

<quote>
A more significant reason is that PerlSwitches must be set before perl starts. 
If you want to set PerlSwitches inside vhosts, and perl has already been 
started, you are out of luck. Here is why you want this feature:

http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlSwitches_
http://perl.apache.org/docs/2.0/user/config/config.html#C_Clone_
http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_

With a <perl> hack section, or a new directive to do just that - force the 
startup of the interpreter, you have a complete control over things. If we 
start early by default, then you're out of control.
</quote>

I fail to see how is that invalid.

So if you want to use some new directives in httpd.conf and set PerlSwitches 
at the same time, you really can't (even as it's now).

__________________________________________________________________
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