Rob, how much stuff do you have in startup.pl? So nothing else is dependent
on Apache.pm modules?
To some degree, because Apache::DBI affects all the Perl interpreters in a
very config-type of way (as opposed to just preloading modules) I like the
idea of it being in PerlModule as it allows some servers to have caching
off and some servers to have it on yet still keep the application level
startup code in startup.pl.
I guess I've always considered startup.pl to be a place for dealing with
the various applications you are using and optimizing them by precaching
selected modules because you really need to use Perl code if you want to do
anything half way complex such as importing namespaces or creating global
singletons in a particular package space.
Whereas, something simple like Apache::DBI which turns on and off caching
seems just as well in PerlModule.
However, I also think that this is unworthy of inclusion into the guide.
PerlModule is well documented. startup.pl is well documented. Documenting
where to put Apache::DBI? That's up to the sysadmin. Doesn't seem worthy of
guide inclusion.
For the complaint about $ENV{MOD_PERL}. I am not quite sure I really agree
that this is a bad thing. Basically, by design you can see in your code
explicitly which code will be run when Mod_perl is running and which code
will not. What's so bad about that?
However, if you really have a problem with this, why don't you create
startup.pl and then a second non-apache-depdenent-startup.pl which is
require'd from startup.pl
Then when you run your script from the command line, just test the
non-apache-dependent-startup.pl being loaded first so that startup.pl only
contains mod_perl specific config. That way you get the best of both worlds.
You could also probably do a check on $INC{'Apache.pm'} or something like
that if you wanted to be a real stickler because in theory it might be
possible to bootstrap a pseudo Apache.pm for non-inside-Apache testing.
Anyway, in all these cases it does seem like there is more than one way to
do it, and advocating a specific way just doesn't seem right for the guide
since I think it is arguable either way.
Later,
Gunther
At 06:17 PM 8/2/2001 -0700, Rob Bloodgood wrote:
> > only if you code it the way you did below, which isn't terribly portable.
> > see http://perl.apache.org/guide/perl.html#use_require_do_INC_and
>
>Ahem, PerlModule is a wrapper around the perl builtin require(). One
>presumes that perl knows where it lives if perl can successfully require()
>it. Especially since this module is installed into the standard perl
>heirarchy as a system module, from CPAN. It's not even XS.
>
> > basically, it's a bad programming practice not to use() modules in the
>code
> > that needs them. it works if you call PerlModule before you use() the
> > module, but again, it requires you to pay better attention to your
> > httpd.conf than you ought to.
>
>See my above point. Apache::DBI is *made* to be transparent, or at least
>semi-. It exists at the server level, and without (much) interaction with
>the programmer's dataspace at all. What better place for it than
>httpd.conf? And as for having to pay too much attention... well... let's
>just say that RedCode is spreading like it is because not enough IIS Admins
>"paid better attention" to the defaults THEY were given. :-) Seriously tho,
>why WOULDN'T you know what exactly is in your server configuration?
>
> > consider writing an Apache module for CPAN, relying on, say, Apache::Log
> > calls, but failing to use Apache::Log in your module. If you have a
> > PerlModule Apache::Log everything works - until somebody else tries to run
> > your code with a different configuration. There's what works and then
> > there's how you ought to do things.
>
>Again, server-level and mostly transparent. And as far as requiring a
>module, 1) I would expect it to be clearly documented 2) and if I didn't
>read the dox I deserve to have wasted the time, and 3) I'll leave 3 for
>below...
>
> > >methods on it are valid, and can be easily wrapped as I suggested
> > >in an "if($ENV{MOD_PERL}) {}" block.
> >
> > this is just a particular gripe of mine, but I think we ought to be
> > past the $ENV{MOD_PERL} thing by now... startup.pl is a mod_perl
> > idiom. if you are designing web applications that depend on things
> > like the mod_perl API, Apache::DBI, and using the hooks into the
> > Apache request cycle then you are already way beyond making a
> > startup.pl script portable between mod_perl and other web
> > environments.
>
>Portable, portable, portable... First of all, understanding that items
>appearing earlier or later in a config file is significant is so common I'm
>astonished you consider it bad manners to see code that depends on it. And
>unless I'm very badly mistaken, it's even significant in httpd.conf as far
>as *Apache* is concerned.
>
>And secondly, you're right, this is *mod_perl*. Not IIS, NSAPI, PHP, or
>Cold Fusion. startup.pl is indubitably a mod_perl idiom. I'm failing to
>understand how this can be considered "portable". But if you mean portable
>from system to system, well, last I heard, ActiveState hadn't quite gotten
>signals or sockets mastered, but I'm pretty certain the have the %ENV
>emulation worked out.
>
>But thirdly, I consider it a convenience to be able to test a script for
>syntax errors before attempting to -HUP my webserver to see if it works or
>not. perl -wc is done almost before I register the cursor moving. apache
>restarts take me at least a minute. It's not about the request cycle, it's
>about the DEBUG cycle. Since I didn't write Apache::DBI, but I have
>reasonable confidence in the guy who did, it doesn't hurt my feelings to
>defer initializing it until I've finished modifying startup.pl for other
>reasons. Which means I can make a change, switch windows, and perl -wc and
>get a syntax check, instead of an Apache error on Apache::AuthDBI, in under
>10 seconds. Or even perl -w (even tho I run w/ -w in the shebang line and
>PerlWarn On) and see debug output I'm working with.
>
>For the record, I also consider it cheesy to have to check $ENV{MOD_PERL}
>but to my knowledge, the Apache $s object isn't passed to startup.pl, and
>setting an environment variable is significantly cheaper than creating a
>perl object in terms of C code and devel/debug time. Remember, the E in
>perl is for "Eclectic." :-)
>
>Idioms are there for a reason: They do well in shorthand a required task.
>Even if there are other, longer ways to do the same thing. TIMTOWTDI. The
>way I "ought to" program is in the way that makes perfect sense when one
>understands all of the pieces, and document the hell out of it so that
>people behind me who don't understand can at least follow the requirements
>list. ESPECIALLY when the person behind me is me, 6 months later.
>
></rant>
>
>L8r,
>Rob
>
>#!/usr/bin/perl -w
>use Disclaimer qw/:standard/;
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/
