in reply to More than mod_cgi less than mod_perl.

As with everyone else, I can't seem to figure out what you want. It appears that what you want is a way to host perl-based web applications that are:
  1. Faster than the standard cgi-bin interface, possibly by eliminating the extra fork per request.
  2. More functional than the standard cgi-bin interface, though this seems to be a minor concern
  3. Easier to use than mod_perl; that is, without the standard mod_perl gotchas
  4. More available than fastcgi or mod_perl. That is, easier for the hosting provider to offer, so that more hosting providers will. Preferably, those providers that don't think about it should be offering whatever this new service is "by default". Certainly, it must be possible to set this up without allowing a clueless script to completely trash the webserver instance for everyone. (aka, "suexec would be nice")

If this is what you want, I think that the last requirement there is going to be the kicker.

First off, any module that requires the perl source code and/or libperl to build all its parts is never going to be in the default apache configuration. This includes Apache::PerlRun, since that depends on mod_perl. It also includes PersistentPerl, mentioned elsewhere, since that requires building a separate executeable linked to libperl.

Instead, may I ask: what's wrong with fastcgi?

In the past, fastcgi was almost killed by licensing issues - I think the original developers were for a while wanting you to pay for access to the module - but that's not the case any longer. mod_fastcgi is open source, and there are fastcgi implementations for most webservers out there. (the webserver world doesn't begin and end with Apache) If your webhost isn't offering fastcgi, switch to one that does, and let your old host know why you're switching. 

--
@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/

[download]

Replies are listed 'Best First'.
Re^2: More than mod_cgi less than mod_perl.
by techcode (Hermit) on Jun 07, 2005 at 21:41 UTC
    You summed it up very good. And I agree, especialy with the 4th.

    First off, any module that requires the perl source code and/or libperl to build all its parts is never going to be in the default apache configuration.
    The way I was thinking is exactly that.

    That's why I said that basicly there is no other thing than mod_cgi and mod_perl. And when I checked the FastCGI it did required you to change the code of the scripts that previosly runed under mod_cgi.

    Anyway, since I got you all interested in this, the reason why I started even thinking about all this is that many people have a (wrong) belif that Perl is slow... Well, slower than PHP.

    Of course Perl is not slower than PHP, and thing that makes it slow is CGI itself.

    Other thing they say about Perl is that it's hard to set up the scripts (set the right path and chmod the files).

    So I started thinking how this could be improved. And mentioned Apache as the most used web server (also has mod_perl) - of course if solution could be aplied to anyother web server, even better.

    I just want to see more people using Perl on the web (for start).
[reply]

      CGI itself is not that slow, but the overhead of loading the perl interpreter and modules is.

      You may want to look at Juerd's PLP and use it to demonstrate to people that Perl kicks PHP's ass... As a sidenote, it only performs that well under mod_perl... ;)

[reply]
      I agree that Perl is starting to gain a bad reputation on the web. mod_php is safe to use on shared hosting and mod_perl is not, which leads some people (even fairly experienced developers) to believe that PHP is just naturally faster. I've heard that mod_perl2 solves this with its perchild MPM, which (I think) gives each script its own namespace and runs it as its owner, but I don't expect speedy adoption.
[reply]
        Yeah! That's my point!

        Still, putting it in own namespace doesn't matter much, you could still be able to access other namespaces, right? So it still isn't shared hosting safe.

        Alto when I think about it, it wont be able to mess with anything else's, than what is already yours.

        If mod_perl2 is usable for shared hostings, than great! But is it suitable for them considering other things (memory usage for instance)?

        Still mod_perl requires from you to be a good programmer, and even if it would be shared hosting safe, it wouldn't be for the "masses".

        Alto that way, we (we - as somewhat good programmers :) could write applications for a mass usage on shared hosting - which would be better than where we are now.

        And "masses" couldn't brake anything even if they try writing some bad code, right?
[reply]

In Section Seekers of Perl Wisdom