All the Perl that's Practical to Extract and Report

Making Perl easier

godoy on 2002-01-12T21:55:11

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 problem with mod_perl...

koschei on 2002-01-13T08:31:22

...is 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 the PHP core (for lack of a better word) is a problem in the event of it being updated. The sysadmin has to go and recompile/install PHP. With mod_perl, if you've got a PHP-like Mason/embperl/template system set up, the user can just use an autohandler to add their own lib directory with newer DBI, or whatever, libraries.

The sysadmin would only need to get involved were mod_perl itself require upgrading. The users could probably live without using their own mod_perl handlers.

And they'd have a consistent name space =)

Re:The problem with mod_perl...

godoy on 2002-01-13T13:40:36

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 modules that depended on it simultaneously, it would be much easier! Now, imagine if I use some module in a specific version that works with mod_perl 1.25 and stops with 1.26 and my admin updates mod_perl? My application stops until I upgrade the module by myself.

OTOH, I can write light applications with mod_perl, since it's clean and not bloated in features. I have only what I need, no more no less. :o)

Re:The problem with mod_perl...

koschei on 2002-01-13T16:47:32

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.