Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Perl Software Programming Apache

Help Test mod_perl 2 Release Candidates 54

Posted by timothy from the yes-master dept.
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."
This discussion has been archived. No new comments can be posted.

Help Test mod_perl 2 Release Candidates More

Help Test mod_perl 2 Release Candidates

Comments Filter:

  • Is mod_perl a legacy technology? (Score:3, Interesting)

    by LizardKing ( 5245 ) on Sunday December 26, 2004 @11:07AM (#11185052)

    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)

      by sporty ( 27564 ) on Sunday December 26, 2004 @11:21AM (#11185142) Homepage
      Uh. noo... mod_perl is old as an idea, but it's certainly not legacy in the same way that dbase is legacy. Only thing bad about mod_perl is trying to use it with apache2 in its threaded mode.


      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 .net, not so much.


      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:4, Informative)

      by Anonymous Coward on Sunday December 26, 2004 @11:22AM (#11185143)
      Well, there is of course slashcode [slashcode.com], and Amazon.com also uses mod_perl and HTML::Mason (see http://www.masonhq.com/?AmazonDotCom/ [masonhq.com]). I'm sure there are many others as well.

    • Re:Is mod_perl a legacy technology? (Score:4, Informative)

      by Airwall ( 39346 ) * on Sunday December 26, 2004 @11:33AM (#11185197) Homepage

      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.

      • A minor quib. JSPs get compiled into servlets, usually. At least tomcat does. It turns the jsp into java source extending servlet or something like.
      • 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. (emph. mine)

        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
    • haven't things like J2EE, .Net and PHP made mod_perl obsolete?

      No, just because there is something newer and flashier I am not going to rewrite a C/Perl system to J2EE or .Net for no substancial gain in the end product.
    • I'm actually developing new sites with AxKit [axkit.org].
    • Actually, mod_perl is running larger sites than Java or PHP right now. ticketmaster.com, citysearch.com, imdb.com, and of course slashdot itself. Although they don't use mod_perl, Yahoo and Amazon use Perl for major parts of their sites. So, it is a popular choice for building very large sites.

      Coding with mod_perl is nearly identical to using Java servlets or ASP in terms of the processing model.

    • I'm thinking of switching to mod_perl, and I don't even like perl. I have alot of PHP pages that load just way too much on every request, and a lot of custom built servlet-frameworks because I don't like any of the existing java frameworks. Lately I've come to the conclusion (and reaffirmed by Rod Johnson's J2EE books) that it's really okay to put your application stack all together as long as it's logically separated. My only complaint is that it seems most of the perl knowledge is locked up in the mind
    • I don't see why they wouldn't. I really think it comes down to what best fits your situation and what skills you have. I think PHP is great and I'm a casual programmer but I think the lack of namespaces can be super confusing in large projects. I've used Perl and its got tons of features and mod_perl is incredibly fast but its to say the least confusing. .NET is stuck to MS servers to the most part. Its just using what works best for you.
  • Well I did a port from mod_perl 1 to mod_perl 2 many months ago, and it wasn't too bad except for the lack of completed version 2 documentation and I wished I had more examples available to me. Most of the docs then were about 50 to 80 percent completed.

    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).

  • "use Apache2" considered harmful (Score:4, Informative)

    by merlyn ( 9918 ) on Sunday December 26, 2004 @03:32PM (#11186211) Homepage Journal
    Keep in mind that this release does not play well with others, especially prior mod_perl1 installations.

    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)

      by Anonymous Coward
      Remember also that under Windows AP2/MP2 is the only stable option currently available.

      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
  • I've been using mod_perl2 over a year now, and it rocks hard. I've got my SMTP handling done through Apache::Qpsmtpd, and I'm currently created a DAV handler for mod_perl2.
  • Would anyone really consider mod_perl for a serious sized web application? [unrisd.com]
    • If you read the rest of the comments you'll see that it is already being used for applications larger than most people every work on.

    • Re:mod_perl (Score:2, Informative)

      by Silent1 ( 546110 )
      slashdot big enough for ya?

    • Re:mod_perl (Score:4, Informative)

      by innerweb ( 721995 ) on Thursday December 30, 2004 @05:59AM (#11217605)
      Are you kidding? PHP, Java and the rest do not have bigger applications than what are done in Perl using mod-perl!

      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

  • Is that there's currently no way to restrict Perl* directives from being specified in .htaccess files. This makes it insecure for hosting servers to use mod_perl. Server admin certainly doesn't want normal clients to access mod_perl. Otherwise, mod_perl could be useful for server admins to customize their webserver.

    mod_ruby on the other hand now has RubyRestrictDirectives to do exactly that.

Slashdot Top Deals

Ocean: A body of water occupying about two-thirds of a world made for man -- who has no gills. -- Ambrose Bierce

Close