Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

godoy (2167)

  (email not shown publicly)
AOL IM: godoy0 (Add Buddy, Send Message)
Yahoo! ID: jgodoyf (Add User, Send Message)

Never doubt how stupid people can be.

Journal of godoy (2167)

Saturday January 12, 2002
04:55 PM

Making Perl easier

[ #2085 ]

I'm creating several RPM packages for Conectiva Linux that contains Perl modules. While doing that, I was thinking that we could have something like binary builds of every module for every platform.

It would require a lot of storage space, but as a 'cluster', each CPAN contributor could store packages for it's own platform. The biggest could store for the most common platforms.

The point is: users don't know how to compile things. Giving them packages (hence binary files) is much better than modules (i.e. source files).

It would make Perl more accessible to people that today uses PHP (that has a lot of functions in its core, while even for DB access Perl has to load modules).

bcm, on #modperl again, said that having means to make mod_perl configurable on a per user basis would also make it more accessible to ISPs.

While it doesn't happens, I'll keep on making packages for Conectiva Linux... I hope they also get built on Alpha, PPC and S/390, besides x86.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • that it does more, but less, than PHP.

    This is a good thing, but it does mean that configuration and preparation is more complicated.

    PHP is a content handler. mod_perl plugs in everywhere.

    Heck, there's not really a comparison to be made between the two, since you have to have Mason, Template or Embperl configured in mod_perl before you get PHP-style code/HTML integration.

    mod_perl just does so much more it's not feasible to have it compete with PHP. They're too dissimilar.

    The 'completeness' of
      ---ict / Spoon
    • Since I've written much less PHP than mod_perl, I'm not able to talk about both on the same level...

      I don't disagree with you on the mod_perl more generic approach. In fact, it is both one of its strengths and failures.

      The whole point is to make things easier to be accessed. If mod_perl is so much better than PHP, why we have difficulties finding out ISPs that support it?

      The main problem, IMHO, is still the way modules are disposed. If the admin of a mod_perl site could upgrade mod_perl and all module
      -- Godoy.
      • I'd say ISPs don't support it because it's too damn difficult for them to set up effectively.

        For raw mod_perl use, developers have to modify the httpd.conf. And get it right.

        It should be possible for them to set up a Mason/Embperl option though.

        And for the average shmoe, badly writing a PHP page is just as good as badly writing a Mason/Embperl page.

        To the admin, the PHP is easier and faster to setup.
          ---ict / Spoon