All the Perl that's Practical to Extract and Report
use Perl Log In
godoy (2167)
(email not shown publicly)
http://www.g2ctech.com/
AOL IM: godoy0 (Add Buddy, Send Message)
Yahoo! ID: jgodoyf (Add User, Send Message)
Jabber: godoy@jabber.org
Never doubt how stupid people can be.
Making Perl easier
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.
an endless discussion thread about what features to include.
-- Jarkko Hietaniemi
The problem with mod_perl... (Score:1)
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
Re:The problem with mod_perl... (Score:1)
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.
Re:The problem with mod_perl... (Score:1)
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