Adam Prime wrote:
I realize this list has been completely dead for a year now, but i'll
give this a shot anyway. I saw this today.
http://perlbuzz.com/mechanix/2007/12/simple-apachefastcgicatalyst-c.html
And I wondered if anyone might want to address the comment 'mod_perl is
bloated'. I'm sure it's 'bloated' compared to FastCGI, but FastCGI and
mod_perl are barely comparable.
Where there is smoke, there is fire. But watch out for the mirrors.
Interesting that his cookbook link leads to this:
mod_perl Deployment
mod_perl is the best solution for many applications, but we'll list
some pros and cons so you can decide for yourself. The other
production deployment option is FastCGI, for which see below.
There was some concern at ApacheCon that the mod_perl core is difficult
to maintain because it is mostly written in XS. One person suggested
that a thin wrapper around the Apache API would be a logical next step.
There is a performance hit to that approach, but the maintainability
of the core would likely go up.
I think that a lot of times when FastCGI is compared to mod_perl it
really needs to be compared to ModPerl::Registry and Apache::PerlRun,
Gozer gave a talk about this at Apachecon, and the room was packed.
Those are the people trying to decide between mod_perl and fast_cgi.
I think that ModPerl::Registry should split off from the core, and be
independent like Apache::Reload is in the process of doing. That's a
dev topic though and I'll leave that to the dev list.
But you can read the comment i've
already left yourself.
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
