PHP Modules?

[Mike]

I'm fairly new to PHP, but a long time Perl coder.

This is probably answered somewhere, but I haven't been able to find
it. The "strength" behind Perl is in its modules; are there modules
available like that for PHP?

TIA,

Mike

[Jan Pieter Kunst]

Re: PHP Modules?

In article <46cdc619.04042 10947.411fbd45@ posting.google. com>,
csdude@hotmail. com (Mike) wrote:
[color=blue]
> I'm fairly new to PHP, but a long time Perl coder.
>
> This is probably answered somewhere, but I haven't been able to find
> it. The "strength" behind Perl is in its modules; are there modules
> available like that for PHP?[/color]

There is a lot of interesting stuff at http://pear.php.net/.

JP

--
Sorry, <devnull@cauce. org> is een "spam trap".
E-mail adres is <jpk"at"akamail .com>, waarbij "at" = @.

[Brendan Donahue]

Re: PHP Modules?

Mike wrote:
[color=blue]
> I'm fairly new to PHP, but a long time Perl coder.
>
> This is probably answered somewhere, but I haven't been able to find
> it. The "strength" behind Perl is in its modules; are there modules
> available like that for PHP?
>
> TIA,
>
> Mike[/color]
You would probably be looking for php "classes" or "extensions ". Many sites
such as http://php.net http://pear.php.net and http://hotscripts.com has
classes for many needs.

[gunzip]

Re: PHP Modules?

Mike wrote:
[color=blue]
> The "strength" behind Perl is in its modules; are there modules
> available like that for PHP?
> Mike[/color]

You have to be joking, Mike. CPAN is the reason I gave up on Perl for web
development and started using PHP. Basically to get Perl to perform as
quickly as PHP you need mod_perl, which doesn't handle memory in shared
environments as well as mod_php does. Consequently many hosting services
don't offer mod_perl.

CPAN modules, despite what everyone on the Perl lists tell you, are
notorioulsy unreliable when compiling. I have a Fedora box running Apache
2.0.48 and a G5 running Apache 1.3.29 on Panther. To get the same templating
features as PHP offers I would need Perl 5.8 + mod_perl + Apache::Templat e
or HTML::Mason. Well, Apache::Templat e doesn't work with Apache 2 so that
limits me to the G5 running Apacha 1.3.29. When I tried to install
Apache::Templat e via perl -MCPAN -e shell it wouldn't compile and left no
clues as to the reason why. As for HTML::Mason it won't work with Apache
2/mod_perl-1.99, which is now the default for Red Hat Enterprise Linux and
Fedora.

I've had MANY, MANY Perl module compilations fail in perfectly good UNIX
environments (OSX, Linux) and I'm sure this has something to do with why
many ISPs only offer a limited range of Perl modules.

Please don't take this as a flame against Perl because I started with Perl
and grew to love the syntax. I reluctantly switched to PHP for web
development because Perl CGI with CGI.pm is simply no match for mod_php.
Perl made the mistake of not offering a decent templating system as part of
the core. Sure, there are many good Perl templating systems (Template
Toolkit, Mason, Embperl) but they all require mod_perl for decent
performance and have many dependencies. Listen to the mod_perl developers
and you will learn that mod_perl gives unseasoned developers "plenty of
rope". That's also true for sysadmins who have to manage mod_perl processes
and shared memory. Most virtual hosting companies won't touch mod_perl so
Perl is reduced to dog-slow CGI. Endgame = PHP is becoming the de facto
standard for webdev. The Perl gurus don't care because they're all sysadmins.

The level of expertise required to get the best out of mod_perl is the
reason many developers of small-to-medium websites have turned to PHP -
because you don't need any modules and you have the same performance as
mod_perl BY DEFAULT, without the need to know all the ins and outs of Apache
processes simply to keep it running safely. PHP made the smart move of
aiming at the web development/HTML templating area that Perl neglected and
bundled everything needed into the core. PHP's strength is the fact that you
don't need modules.

I'm sure there are many PHP programmers, like myself, who reluctantly
migrated from Perl but who would have preferred not to have been obliged to
do so because they prefer Perl as a language. I blame the Perl community for
keeping their heads in the sand while PHP stole their ground in web development.

gunzip

[nospam@geniegate.com]

Re: PHP Modules?

gunzip <none@none.co m> wrote:

[color=blue]
> I'm sure there are many PHP programmers, like myself, who reluctantly
> migrated from Perl but who would have preferred not to have been obliged to
> do so because they prefer Perl as a language. I blame the Perl community for
> keeping their heads in the sand while PHP stole their ground in web development.[/color]

I still perfer perl, but for all the reasons you mention I've switched
the web side to PHP. (for the most part, I'd still use mod_perl for it's
speed and power where it's available, I use it with swish-e for my
search page, and a few intranet level things)

Anyone ever use PHP on the web front, but then have PHP talk to a
middle-tier written in perl?

Jamie
--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX

[gunzip]

Re: PHP Modules?

nospam@geniegat e.com wrote:[color=blue]
> I still perfer perl, but for all the reasons you mention I've switched
> the web side to PHP. (for the most part, I'd still use mod_perl for it's
> speed and power where it's available, I use it with swish-e for my
> search page, and a few intranet level things)
>
> Anyone ever use PHP on the web front, but then have PHP talk to a
> middle-tier written in perl?
>
> Jamie[/color]

Case in point, the default Perl 5.8.1/mod_perl-1.26/Apache 1.3.29 which
comes with OSX Panther doesn't even have Perl's print() working under
mod_perl. That's how bad it gets with all these combinations. Sure, I could
re-install from source but I'd have to learn how to un-install the current
setup first AND reproduce what I had = non-trivial. In the meantime, I have
work to do. Perl is fine if you have endless hours to track down module
incompatibiliti es and futz with your OS all day like a Debian/Gentoo freak
trying to get his hardware working. PHP, to me, is what Red Hat is to Linux
- works cleanly out of the box so that I can be productive. If the likes of
Apache::Templat e and HTML::Mason still can't get it working with
mod_perl-1.99 and Apache 2 after all this time (how long have we had Apache
2 now?) then I have no confidence at all in using these solutions.

Have you noticed how upgrades of Perl and its major modules are taking
longer and longer between upgrades? Christ, we'll be lucky to see Perl 6
this side of the next decade the way it's going. Reason - it's getting ever
more complex. Throw Apache 2 into the mix and you have the current chaos
with many module developers ignoring Apache 2 altogether. The reason is that
the more modular you make something (Perl/mod_perl/Mason) the greater the
potential for incompatibiliti es and the slower the release cycle when one
part of the chain has to wait for another to produce a stable version.

Endgame = PHP as de facto webdev language.

gunzip

[nospam@geniegate.com]

Re: PHP Modules?

gunzip <none@none.co m> wrote:
[color=blue]
> Have you noticed how upgrades of Perl and its major modules are taking
> longer and longer between upgrades? Christ, we'll be lucky to see Perl 6
> this side of the next decade the way it's going. Reason - it's getting ever
> more complex. Throw Apache 2 into the mix and you have the current chaos
> with many module developers ignoring Apache 2 altogether. The reason is that
> the more modular you make something (Perl/mod_perl/Mason) the greater the
> potential for incompatibiliti es and the slower the release cycle when one
> part of the chain has to wait for another to produce a stable version.
>
> Endgame = PHP as de facto webdev language.[/color]

Upgrading perl is dicey at best. (Well, thats the case of any language
IMO)

I've had my fill of pulling hair out with mod_perl (mod_bald anyone? :-)
) mod_perl *is* faster than PHP as far as I can tell, but it is very
fragile.

I was just thinking perl could take an example from tomcat / servlet
technology, instead of this whole mod_perl thing. Then, each "perlette"
could be used independant of each other. (separate process)

In the meantime, I suppose one could have a perl process do the heavy
lifting (middle tier) and use PHP to talk to it.

Wish I had the 4 months it would take to design & release something like
servlets for perl.

Jamie

--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX

[gunzip]

Re: PHP Modules?

nospam@geniegat e.com wrote:
[color=blue]
> I've had my fill of pulling hair out with mod_perl (mod_bald anyone? :-)[/color]

You're not the only one.
[color=blue]
> ) mod_perl *is* faster than PHP as far as I can tell, but it is very
> fragile.[/color]

Exactly. The fact that too many things can so easily go wrong with mod_perl
leads me to the conclusion that its design is flawed. Witness the problems
the mod_perl team are having getting it to work with Apache 2. Then, when
they've exhausted themselves with that one they'll be just in time for Perl
6 when everything will be turned upside down again. I'm not arguing against
improving the language, ie. Perl 6 itself, but if it is still dependent on
mod_perl for performance Perl will be history for most web developers. To
compete with PHP in the web development sphere Parrot will be the deciding
factor. If Parrot can get Perl up to mod_php speed without recourse to
mod_perl then I'd be interested in taking another look at it. Perl 6 also
needs to have something like Template Toolkit bundled in the core.

A tool that can only be used effectively by Apache internals experts (ie. to
avoid "hanging" themselves) is a tool which is practically useless. Mod_perl
gurus love to look down on lesser mortals but that'll be their loss when
more and more potential Perl projects are turned over to PHP. Perl's
dependence on mod_perl for decent performance is it's biggest weakness.

I'm not sure I agree that mod_perl is THAT much faster than mod_php, though.
[color=blue]
> I was just thinking perl could take an example from tomcat / servlet
> technology, instead of this whole mod_perl thing. Then, each "perlette"
> could be used independant of each other. (separate process)
>
> In the meantime, I suppose one could have a perl process do the heavy
> lifting (middle tier) and use PHP to talk to it.
>
> Wish I had the 4 months it would take to design & release something like
> servlets for perl.
>
> Jamie
>[/color]

[nospam@geniegate.com]

Re: PHP Modules?

gunzip <none@none.co m> wrote:[color=blue]
> Exactly. The fact that too many things can so easily go wrong with mod_perl
> leads me to the conclusion that its design is flawed. Witness the problems
> the mod_perl team are having getting it to work with Apache 2. Then, when
> they've exhausted themselves with that one they'll be just in time for Perl
> 6 when everything will be turned upside down again.[/color]

Actually, mod_perl does work with Apache 2, however using it is an
excercise in chasing after non-existant documentation, general
hacking and fear of upgrading apache.

I for one don't understand why EVERYTHING has to be embedded in the web
server. out-of-process client/server stuff allows higher scale because
portions can be tasked out to other machines, apache upgrades are less
likely to break everything else and we can use perl where perl is good,
PHP where PHP is good, etc..

I'll admit there is a slight overhead in doing this, but considering
the benefits I think it's a mostly win situation, local network TCP
connections aren't really that slow.

Jamie

--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX

[Phil Roberts]

Re: PHP Modules?

With total disregard for any kind of safety measures gunzip
<none@none.co m> leapt forth and uttered:
[color=blue]
> Reason - it's getting ever
> more complex.[/color]

You're not wrong. Have you read Larry Walls article on the Perl6
object model over at http://www.perl.com/pub/a/2004/04/16/a12.html?

--
Phil Roberts | Dork Pretending To Be Hard | http://www.flatnet.net/

[gunzip]

Re: PHP Modules?

Phil Roberts wrote:
[color=blue]
> You're not wrong. Have you read Larry Walls article on the Perl6
> object model over at http://www.perl.com/pub/a/2004/04/16/a12.html?
>[/color]
I'm referring really to the ever-increasing dependence on modules to get
things done with Perl. CPAN is fine when you're futzing with your own server
or can ssh with full permissions into your company's server. Anything less
than that and CPAN becomes your biggest liability. Need Template
Toolkit/HTML::Mason? Sorry, we don't offer that "extension" . I've heard
similar from ISPs so many times.

Alas many in the PHP community are heading that way with over-emphasis on
PEAR. Few seem to be aware of the drawbacks of over-modularity. Like CPAN,
PEAR may well end-up suffering from lack of quality control. Without that
the foundations of your work become shakier. PHP was designed, as far as I
understand it, to avoid this problem but it could so easily go PEAR-shaped
:-( if it tries to emulate CPAN.

Case in point, should PHP5 decide that it can adapt to Apache 2's threaded
model the larger PEAR has grown by that time, the larger the amount of
potential re-writing/breaking.

gunzip

[nospam@geniegate.com]

Re: PHP Modules?

gunzip <none@none.co m> wrote:[color=blue]
> I'm referring really to the ever-increasing dependence on modules to get
> things done with Perl. CPAN is fine when you're futzing with your own server
> or can ssh with full permissions into your company's server. Anything less
> than that and CPAN becomes your biggest liability. Need Template
> Toolkit/HTML::Mason? Sorry, we don't offer that "extension" . I've heard
> similar from ISPs so many times.[/color]

That is exactly the reason I seldom used any CPAN stuff for distributed
perl applications. (unless the application expected root access) With
perl, you pretty much have to do all that yourself and create your
own lib so you can avoid the CPAN problem.
[color=blue]
> Case in point, should PHP5 decide that it can adapt to Apache 2's threaded
> model the larger PEAR has grown by that time, the larger the amount of
> potential re-writing/breaking.[/color]

I personally like java's idea of jar files and classloaders, BUT that
can even be worse than perl if it's overused. A ".pear" (tarball, etc..)
of packages of packages so you could distribute your code using known
libraries seems to be the best defense. (and also the most bloated
because each application may have an identical copy of the same library)

Jamie

--
http://www.geniegate.com Custom web programming
User Management Solutions Perl / PHP / Java / UNIX

[gunzip]

Re: PHP Modules?

nospam@geniegat e.com wrote:
[color=blue]
> That is exactly the reason I seldom used any CPAN stuff for distributed
> perl applications. (unless the application expected root access) With
> perl, you pretty much have to do all that yourself and create your
> own lib so you can avoid the CPAN problem.
> Jamie[/color]

Last I heard Perl 6 is going to have even less in the core so CPAN module
dependency will increase. This has to be the worst move Larry Wall ever made
if he cares about the adoption rate of Perl. Maybe this has been revised
recently?

gunzip

[Andy Hassall]

Re: PHP Modules?

On Thu, 22 Apr 2004 19:41:04 GMT, nospam@geniegat e.com wrote:
[color=blue]
>I for one don't understand why EVERYTHING has to be embedded in the web
>server. out-of-process client/server stuff allows higher scale because
>portions can be tasked out to other machines, apache upgrades are less
>likely to break everything else and we can use perl where perl is good,
>PHP where PHP is good, etc..[/color]

FastCGI looks quite interesting here; it's persistent processes for various
languages outside the webserver, and allows running remotely over TCP or
locally through IPC. Been meaning to look into this a bit more closely; if it
works, looks like it could give many of the advantages of mod_perl without the
headaches.

--
Andy Hassall <andy@andyh.co. uk> / Space: disk usage analysis tool
http://www.andyh.co.uk / http://www.andyhsoftware.co.uk/space

[gunzip]

Re: PHP Modules?

I found this on the Perl 5 Porters list:

<quote>
the perl distribution is already too big. We can't trim it
for backward-compatibility reasons but the core distribution
of Perl 6 will probably include only the modules that are
absolutely necessary to fetch and install the others.
</quote>

This could be taken 2 ways:

1. The Perl 6 core has no core modules/pragmata but there exists a bundle of
standard modules without which would be more or less essential to complete
the installation. If this new set of core modules expands beyond the current
set to make most webdev possible without much else then we have a definite
improvement.

2. Perl 6 cares even less about which webdev tool is popular, leaves
everything but the basics out of the core and leaves the end user with even
more ways to do it. ISPs suit themselves which modules they wish to install
and no-one can rely on modules for distributed applications. Same as we have
now but possibly worse.

OK, Perl is an all-purpose language so maybe we shouldn't expect it to make
decisions about its core based on the same criteria as PHP's. I reckon it
will probably become largely the preserve of sysadmins in the long run, though.

gunzip