![Perl Perl](http://a.fsdn.com/sd/topics/topicperl.gif)
![Software Software](http://a.fsdn.com/sd/topics/software_64.png)
![Programming Programming](http://a.fsdn.com/sd/topics/programming_64.png)
![Apache Apache](http://a.fsdn.com/sd/topics/apache_64.png)
Help Test mod_perl 2 Release Candidates 54
stas writes "After almost 3 years of work mod_perl 2 is almost ready for its 2.0.0 release. We plan to make the gold release in a few weeks. Please help to test the release candidates by starting to port your mod_perl 1 applications to mod_perl 2. Make sure to read the documentation and report
any problems that you may have discovered. Thanks."
Is mod_perl a legacy technology? (Score:3, Interesting)
Not a troll, but something I'm genuinely wondering about - haven't things like J2EE, .Net and PHP made mod_perl obsolete? Back in the bad days of the web, the choice was C or Perl hooking directly into the Apache API to avoid spawning too many processes. Then along came Java servlets or ASP for those drawn to the dark side. Would anyone really consider mod_perl for a serious sized web application any more?
Re:Is mod_perl a legacy technology? (Score:4, Insightful)
Btw, php does not make mod_perl obsolete. Yes, php can be hosted in a lesser secure area, as php scripts assume the user its running as, but that's about it. It's an ugly language full of redundancy, bugs and inconsistent style. j2ee and
Biggest problem with php, is their "modules" are c-compiled. There is the least portability with it. With perl, perl written modules, not the XS modules, can be easily copied anywhere. j2ee not so much, as the configuration files change format from server to server. But from os to os, they are the same.
Re:Is mod_perl a legacy technology? (Score:2)
Re:Is mod_perl a legacy technology? (Score:2)
An error in my phrasing of that.
Re:Is mod_perl a legacy technology? (Score:2)
You can't say it's uglier than Perl. Although at least Perl doesn't gives you error messages like "unexpected T_PAAMAYIM_NEKUDOTAYIM" which is only funny to anyone who speaks Hebrew.
Re:Is mod_perl a legacy technology? (Score:4, Informative)
Re:Is mod_perl a legacy technology? (Score:2, Insightful)
Re:Is mod_perl a legacy technology? (Score:1)
Re:Is mod_perl a legacy technology? (Score:1)
Re:Is mod_perl a legacy technology? (Score:1)
Re:Is mod_perl a legacy technology? (Score:1)
Re:Is mod_perl a legacy technology? (Score:4, Informative)
It's not really fair to equate mod_perl to per-page interpreted languages.
mod_perl, and to a certain extent Java servlets, gives you a huge amount of power over the web serving process, and are suitable for developing web applications that can do almost anything with HTTP.
PHP, ASP and the like give you a per-page interpreted language, oriented to producing one page of HTML at a time. They are much easier to get started with, and they're the "right" choice for most websites.
Of course middle-men between the two camps exist: Servlets have JSPs, for example, which obey a per-page paradigm but are run by servlets. There are also third-party templating system with greater or lesser degrees of flexibility/depth/power (Tapestry [apache.org] is a particularly impressive one.) My own website (http://n3dst4.com , rather than the one in my profile) is written in Mason [masonhq.com], which is an interpreted component and template layer on top of mod_perl. Because of the depth of control that mod_perl has, Mason can do some things that PHP can't, like having a completely programmable request handler, global or per-directory pre-handlers, a seamless component model).
I'm not dissing PHP, though. The site in my profile (Sacred Steel) is written in PHP, because it was the right tool for that job.
Oh, and remember that .net and J2EE are allegedly complete enterprise programming platforms, while mod_perl is just one specific technology for web application programming.
Re:Is mod_perl a legacy technology? (Score:2)
Re:Is mod_perl a legacy technology? (Score:2, Insightful)
even as you attempt to broaden the sense that mod_perl is more than just some content generating script, you undermind the essence of what you talk about.
mod_perl is capable of being used to write entirely different protocol handlers [apache.org]: you can make apache serve FTP or ssh with mod_perl, if you're
Re:Is mod_perl a legacy technology? (Score:2)
No, just because there is something newer and flashier I am not going to rewrite a C/Perl system to J2EE or
Re:Is mod_perl a legacy technology? (Score:3, Interesting)
Re:Is mod_perl a legacy technology? (Score:1)
Re:Is mod_perl a legacy technology? (Score:1)
Playaholics: Free online games: Lightning Pool [playaholics.com]
Re:Is mod_perl a legacy technology? (Score:2)
Coding with mod_perl is nearly identical to using Java servlets or ASP in terms of the processing model.
Re:Is mod_perl a legacy technology? (Score:2)
Re:Is mod_perl a legacy technology? (Score:1, Interesting)
Re:Is mod_perl a legacy technology? (Score:3, Informative)
Re:Is mod_perl a legacy technology? (Score:2)
Re:Is mod_perl a legacy technology? (Score:2)
Re:Is mod_perl a legacy technology? (Score:1)
From the blurb:
Maypole is a Perl framework for MVC-oriented web applications, similar to Jakarta's Struts. Maypole is designed to minimize coding requirements for creating simple web interfaces to databases, while remaining flexible enough to support enterprise web applications.
(Note that I'm not fully objective as I'm one of the developers working on Maypole
Re:Is mod_perl a legacy technology? (Score:2, Insightful)
porting okay except unfinished documentation (Score:2)
The porting itself was painless when I wasn't trying to set up a build environment across multiple Apache and perl versions and using libapreq2 [apache.org] (lib ApacheRequest) and mod_perl2 (well 1.99).
Re:porting okay except unfinished documentation (Score:2)
a huge shout out to the mod_perl team for not only documenting their own efforts, but for finally making some sense of Apache's scattered api.
"use Apache2" considered harmful (Score:4, Informative)
In order to have two different versions of things like Apache::Request (which have changed implementations without changing names), the modules get installed as $libdir/Apache2/Apache/Request.pm. Of course, you're then expected to "use Apache2" to add $libdir/Apache2 to your @INC path. Of course, this breaks every other element of the Perl toolchain that expects that @INC is not changed in such a radical fashion.
This release currently has problems with the PAUSE indexer, the CPAN installation tools, perldoc, and installation of manpages, because they all expect @INC to not be so badly hacked. Stas is trying to work out solutions with the community, but mostly in the form of "This is the way modperl2 works, please fix all your tools", and that's not flying well.
So, beware to those who install this release.
Re:"use Apache2" considered harmful (Score:2, Insightful)
Personally I have been using MP2 in production on windows for well over a year - call me an early adopter
FYI the only problem the windows install has ATM is the a bug that took from perl5.8.3 to perl5.8.6 to fix.
On the linux side the benefit of the reduced memory profile and increase in performance we have seen is enough to migrate new installations to AP2/MP2. We have yet to have a problem on the Linux side and no
Thanks to the developers (Score:1)
Re:Thanks to the developers (Score:2)
Re:Thanks to the developers (Score:2)
Re:Thanks to the developers (Score:1)
mod_perl (Score:1)
Re:mod_perl (Score:2)
Re:mod_perl (Score:2, Informative)
Re:mod_perl (Score:4, Informative)
It has more of a learning curve than php at first, and probably is not appropriate for small static sites, but I have never seen PHP or Java rip out major stuff as fast as Perl, then migrate, modify or otherwise perform client expectations that require redesign. I have worked for two companies where we went to Java. At both companies, more than half the stuff that went to Java was sent back to perl to decrease response time for client needs. Another company I contract to went to PHP for their site when they started, but wound up re-writing the whole thing in Perl with mod_perl when they had a database change. It was faster, and the code came out more manageable, faster and more stable. We learned very quickly that a programmer who writes bad code does it in all languages, and all the good programmers wrote clean concise well documented code (most of the time). And when they wrote something sloppy, it was no more difficult to figure out what they had written than it was in the other languages (Java, php, C, C++, sql, ...)
It is very simple. I am paid by my clients to provide, maintain and modify code. They expect that I will charge them less than others and provide strong solid support and service. Most of them expect one day to one week turn around for change requests. Since we manage the code ourselves, it is very important to us that the code be quick, clear and concise. It must be as reuseable as possible. It must be able to be picked up with and run by new people or contractors. The Java took too long to make the same things happen and PHP ran into dead ends (could not, or more often took too long) when upgrading sites, migrating to new client databases or other client changes. In short, Perl has allowed us to undercut almost all of our competitors in this area. The ones we have not undercut are, believe it or not, perl based shops as well. Java does beat perl for some things as does php for some things, but in so many cases, perl has beat them both.
InnerWeb
One complaint about mod_perl (Score:2)
mod_ruby on the other hand now has RubyRestrictDirectives to do exactly that.