perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randolf Richardson" <>
Subject Re: Enquiry about mod_perl project state
Date Sat, 15 Aug 2015 16:34:34 GMT
	(This reply to Dr. James Smith's message is also intended for Ashish 

	You're hooking in to more handlers than I typically do -- I hook 
into PerlAuthenHandler and PerlAuthzHandler (to implement a custom 
login system I created that uses one cookie, so it's been great that 
cookies are accessible at these stages), so that's two places (I 
found that I have to set up handlers for both or else neither works, 
which is fine because simply returning Apache2::Const::OK for authz 
is trivially easy).

	In my test environments, I use PerlInitHandler with Apache2::Reload, 
which I find does come with a slight performance hit, but that's okay 
because they're not as busy as the production environments.

	So, aside from that I use PerlRequire to load my main module (which 
includes the "authen" and "authz" handlers), and then I use the 
following stanza in a VirtualHost container in httpd.conf to handle 
all .pl files with mod_perl:

  <FilesMatch "(\.p[lm]|^[^\.]+)$">
    SetHandler modperl
    PerlOptions +SetupEnv
    PerlResponseHandler ModPerl::Registry
    AddOutputFilter INCLUDES .pl
    Options +Includes +ExecCGI

	My main Perl module, at the authen() stage, connects to PostgreSQL 
with DBI using connect_cached, and then stores a referenced to itself 
with $r->pnotes, which is later used by all the .pl files in my web 
sites to use the same database connection (why waste CPU resources by 
reconnecting and re-processing the cookie twice when we can just 
re-use what's already been established in the authen() stage?).

	One of the nice things about using the pnotes mechanism is that it 
also means that I can write my .pl files in a generic manner so that 
they can easily be copied to other web sites that use different main 
modules (as long as I support the same functions for generating 
headers and footers, and other web site styling, which I do).

	For me, mod_perl has been an amazing productivity tool, and I've 
been building nearly all my web sites with it (where I don't use 
mod_perl is when all I need is plain HTML without any server-side 
functionality).  One of the greatest things about using mod_perl is 
the consistently high performance it provides, even when enduring 
heavy traffic loads (there are limits, of course, but comparatively I 
find that mod_perl handles a lot more traffic than many other systems 
like PHP, and so hardware infrastructure costs are less overall too).

> I agree with Randolf,
> I have watched a number of projects move away from mod_perl - often to 
> Dancer/
> Catalyst etc and then they ask can I do X, Y or Z...
> I say "if you were using mod_perl you could do that easily" but usually 
> find the tool chain for
> doing something similar in Dancer or Catalyst is infinitely more 
> complex, because you can't
> simply add a handler here or an output filter there. You can do this 
> with chained middleware
> in Dancer but it is not that easy to implement...
> The main thing with mod_perl is - as long as Apache doesn't mess around 
> with the core HTTPD
> interface (like they did with 2.4) then there isn't anything much that 
> needs changing - because
> it is good solid and just works... If it ain't broke then it doesn't 
> need changing.
> I probably use more "pure" mod_perl - no registry scripts here thank 
> you! - and hook into the
> apache process at about 7- 8 places to handle users, templating, 
> diagnostics, optimisation etc
> On 14/08/2015 18:51, Randolf Richardson wrote:
> >> Hello,
> >>
> >> I wanted to enquire about the status of mod_perl, since there is largely an
> >> impression it is end of life. The project site also does not say much. I
> >> see many of the mod_perl shops now moving to perl Dancer/Mojolicious etc.
> >> or going the Java way.
> > 	I'm still using mod_perl to develop new web sites.  The most recent
> > one I've published is called the "atheist Blog Roll" and it uses a
> > PostgreSQL database in the back-end:
> >
> >
> >
> > 	There are other projects on my horizon that continue to be developed
> > in mod_perl, and they range from simple web sites to fully
> > interactive projects.
> >
> > 	When there is a need for a client-side application, I use Java
> > because I only have to write the code once to gain support on
> > multiple Operating Systems (e.g., Unix/Linux, Windows, MacOS), and if
> > it needs to interact with a web site, then I typically use mod_perl
> > for that end of things.
> >
> > 	For one of the projects I'm working on (which is not ready for
> > public consumption quite yet), I've also written a WHOIS server using
> > mod_perl (which listens on TCP port 43, and responds to queries based
> > on its findings in PostgreSQL) to facilitate public membership record
> > lookups (only for the portions that will be publicly accessible).
> >
> >> What is the future of mod_perl beyond mod_perl 2.0? What is the upgrade
> >> path recommended by the mod_perl veterans?
> > 	When I upgrade, I'm normally installing new server hardware and so I
> > migrate sites over one at a time, and resolve any API change
> > requirements before promoting the new server to production (followed
> > by log file merges after switching servers and traffic to the old
> > servers cease).
> >
> >> Regards,
> >> Ashish
> > Randolf Richardson -
> > Inter-Corporate Computer & Network Services, Inc.
> > Beautiful British Columbia, Canada
> >
> >
> >
> -- 
>  The Wellcome Trust Sanger Institute is operated by Genome Research 
>  Limited, a charity registered in England with number 1021457 and a 
>  company registered in England with number 2742969, whose registered 
>  office is 215 Euston Road, London, NW1 2BE. 

Randolf Richardson -
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada

View raw message