Greetings.
[...]
> includes a
> big chunk of the wisdow that passed through this list in the
> last 5 years.
I know this is frivolous but:
wisdow= wisdom+windows+widows ?
Three in one - Humpty Dumpty would have been delighted....
Just to avoid making this contribution to the thread utterly useless, I'll
add
my 0.02 of personal experience.
I have been coding a (straight)CGI/mod_perl/FastCGI (meaning it runs
unmodified under all 3 environments) application on Win32.
I have never incurred (both by foresight, experience and a good dose of
sheer luck) in any of the pitfalls mentioned in the guidebook. The technical
device
which has kept this working has been a very small main:
#Unimportant details omitted.
use strict;
use warnings;
use CGI;
use Foo::Bar;
sub main {
my $q=new CGI;
my $actor=Foo::Bar->new(-query=>$q); #object factory
$actor->main();
}
###Run it###
main();
exit(0);
which delegates everything to a bunch of OO modules which do careful
housekeeping of all package variables (if any) and have explicit destructors
where externally allocated resources are used (this is especially important
for my application,
which uses Win32::OLE quite heavily, which makes keeping orderly refcount in
the external components of paramount importance).
In addition, I mount an unrelenting watch on the error log and I try to
eradicate all the perl warnings that show up - this always proved to be
well-employed effort, even if it means that I have to pepper my code with
statements like:
snafu((exists($foo->{bar})? $foo->{bar} : ''));
rather than:
snafu($foo->{bar});
What I found out is that, allowing for the peculiarities of Win32 as a
platform (and I am using the term 'platform' loosely), and some limitations
of both Apache and mod_perl in this environment, mod_perl strikes the best
compromise between speed and reliability (though the threading thing looms
in the background - see the guidebook on this).
FastCGI has slightly better speed, but I have seen it hanging (and it does
not look like support for FastCGI is going to be huge in the futuer), while
straight CGI is obviously the speed dog, though not as shabby as one might
think (but is still outperformed by both Apache2/CGI and IIS, though
adapting the app to be also able to run under IIS was a bit of a pain...)
I should add that my app is not geared towards volume serving so performance
has never been my top priority - OTOH, if you are looking at *u*x platforms,
you will find that everything becomes easier...
Cheers,
alf
