I've not completed my research, but I believe that if an ISP offered an Apache::Template environment with the proper safe plugins (and no chance to "escape" to Perl), you'd effectively get PHP-like scriptability with TT as the scripting language, and access to the entire CPAN through approved plugins.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

However, PHP is more like using HTML::Embperl or Apache::Template.

Is this true even if we talk about mod_php rather than using PHP in CGI mode?

Basically, I am just astonished that mod_perl vs. perl as interpreter for CGI scripts seems to be so very different to mod_php vs php as interpreter for CGI scripts. I am wondering how mod_php can reap the benefits of being an Apache module without suffering the same consequences as mod_perl (e.g. shared namespace). Or is mod_perl offering much more than mod_php?

Or is mod_perl offering much more than mod_php?

Yes, but I thought I had already made that point in the first step.

mod_perl is raw access to every phase of the Apache request and service cycle. mod_php is an Apache::Template-like access to the content phase only and thus far more limited.

So to get "mod_perl" to act like PHP, you have to restrict it severely.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

In mod_php an actually executed script is one limited scope within the "big program" that runs all the time, just like a mod_perl handler, but from within that scope you don't have acces to any data "above in the big program"", with mod_perl you have that access and can manipulate that "big program" and that enables you to a) do many much cooler things with mod_perl and b) do many nasty things and break more. Imagine a wrapper under mod_perl that executes a handler and causes _any_ variable in that handler to be declared via my() by default, even those who already exist as globals.

# in PHP this code:
$foo = 'abc';
# creats such a private variable
# in Perl
$foo = 'abc';
# would change the package global $foo
# or yield an error under strict
[download]

Then the handler code would be limited to it very self, comparable to a PHP script. It could still store persistent information through limited interfaces (like the mysql_ functions of PHP). In mod_php that "big program" is not a PHP script itself and there are no "superglobal" PHP variables, in mod_perl there is a "big program" that has a globel scope.

Such a wrapper would mean to emulate Perl with some changes in the guts (concering limitation of access to global variables, sounds strange, is strange).

The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now.

ISPs running mod_php most likely have safe mode on. There is no direct perl equivalent, but like merlyn said, you could setup a handler to run .perlhp files via a HTML::Embperl or Apache::Template handler which would run those through Safe (which may or may not be safe).

I've not seen anyone do this. Why? I don't know. merlyn?

I have contemplated this before, but never gotten around to actually implementing anything.

Makeshifts last the longest.

I work a lot in both PHP and Perl and a modicum in mod_perl. You already have your answer from the folks above, but this is how I view it...

Perl is a Swiss Army Chainsaw - it can carve pretty much anything up.

PHP is a Toothpick - a job it does rather well.

Don't use a chainsaw to clean your teeth! PHP is fine for webpages, and can be designed, structured and well written, using your Perl experience!

However, if you really do want to bring the entire Apache server down from within a page, do hold out for mod_perl

0.02 USD

Y'know, I can't swear it as a fact, but I seem to remember the Swiss Army being rather fond of including toothpicks as a component of their tools...
-----------------------
You are what you think.

Maybe with the knifes, but definitively not with the chainsaws.

Mats

PHP / ColdFusion are definately well suited for their tasks. But I find that the following gets a little irritating.. PHP/CF are pure web languages, it's irritating in CF to have to use a browser to debug code. PHP can be run from a command line, but it's not really a command line language.. PHP/CF has little in namespaces, making it pretty tough to write anything complex without making a mess. mod_perl has the neat ability of being this huge complex beast, or, just a simple text munging engine (See Mason, Apache::ASP, or Template::Toolkit). Slashdot's faq response in concern to PHP vs. mod_perl was a good summation. I guess it just depends on what YOU like. Both are capable of doing what you need.

PHP/CF are pure web languages, it's

That hasn't been true for a while now (in the case of PHP).

MJD says you can't just make shit up and expect the computer to know what you mean, retardo! I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests. ** The Third rule of perl club is a statement of fact: pod is sexy.