PHP5 Co-Creator Interview

mandozcode writes "I came across an interesting interview with PHP co-creator Zeev Suraski at Open Enterprise Trends on the latest upgrades for PHP5's First Release Candidate (just released a week or so ago). Sounds like lots of improvements to help make it in the enterprise, including better bundled support for SQLlite and XML. Also encouraging, looks like Zend is getting more millions in VC investment."

Comments

PHP's broken security model

[Mr. Darl McBride]

I can't take PHP seriously for one reason alone: No built in suid mechanism.

If you enable PHP on your apache server, all PHP runs as the same user. That means any files writable by one PHP script are writable by all PHP scripts. There's no such thing as a secure apache PHP installation unless you run in feature limited mode which breaks virtually all PHP scripts and makes it unusable for most tasks.

Until PHP adds suid so PHP runs as the user owning the script, it's a no-go. Run in high security mode it's usable as a toy at best, or run in default mode, it's a security nightmare.

I've spoken with the PHP developers about this at several conferences. Their solution is that you have each user run their own copy of apache or have each user create their own PHP installation and run everything as CGI, launching the local PHP copy. I'm sorry, but that's insane.

I don't give a lick about new features if you can't get the foundation fixed. Take care of the wet sand base before you up the supported database count or make grand announcements about clever new scripting keywords.

Re:PHP's broken security model

[Gislobber]

I totally agree with your agrument. A friend and I have been searching for a resolution to this for quite a while.

Then the other day, I think he may have found our (temporary) savior.

This module is in development, but looks to be almost *exactly* what we are looking for.
http://httpd.apache.org/docs-2.0/mod/perchil d.html

Re:PHP's broken security model

[sumbry]

I can't take PHP seriously for one reason alone: No built in suid mechanism.

You gotta be kidding, right? I mean this isn't even a concern if you aren't running in a shared hosting environment. Seems a bit premature to toss out an entire programming language that could potentially be beneficial because you don't agree with how it's implemented in one particular situation.

That said, it is entirely possible to get PHP working w/Apache suExec and to automatically have it execute php scripts as the User/Group specified in an Apache VirtualHost block.

http://www.localhost.nl/patches/phpsuexec_howto. ht ml

Php in the enterprise? Scary thought.

[neiras]

Since its inception, PHP has gone from a simple website templating language and form processing tool, to a semi-OO scripting language hacked onto a bunch of C extensions, and now they expect to become a fully OO, enterprise-ready language?

Scary.

To write web applications properly and efficiently, you need a framework to support you. You do NOT want to be reinventing the wheel. Have you noticed the massive proliferation of database abstraction layers, incompatible form processing libraries, etc. etc. all written in PHP for PHP developers? Libraries of code written in a templating language! Eep. Every reasonably experienced PHP developer has probably tried to create an application framework at some point - if people keep seeing the need for one, it's a good bet PHP needs to supply one. No, PEAR is not an application development framework.

And what is it with all those PHP developers who seem to think a "class" is another term for "static function library"? The concept of using object types is foreign to thse people - they'd rather make huge monster arrays.

Just because the "I Can Use A Database So I Must Be A Web Developer" crowd thinks every web app could and should be written in PHP does NOT mean that that's actually the case.

PHP downright _encourages_ beginners to embed application-logic in HTML pages. I've been through a rewrite of an absolutely MASSIVE PHP site, and it was a year-long affair for five developers. The old site had become impossible to maintain. Talk about a waste of resources.

When PHP adopts a *standard* way of separating content logic from application logic, and enforces that split (kind of the way JSP pages work with servlets), then _maybe_ there will be some hope for it in the enterprise. Until then, Java will continue to dominate. I find it funny that Java interaction is such a high priority for PHP - if Java's installed on a company's hardware, a developer's natural reaction would be to use Java, not write something in some other language.

Re:Php in the enterprise? Scary thought.

[wan-fu]

I do agree that all too often applications are rammed into PHP without too much forethought; however, I think PHP is already going in the right direction for enterprise level development. The object orientedness of the language is much improved since PHP3. They have the Smarty template engine which does a fairly good job of separating presentation from application. People should be encouraged to use it and I think as PHP apps get bigger, people will begin to realize the advantage to separating design logic from application logic. Most importantly, there are a variety of third-party developers creating frameworks such as the Horde framework or Blueshoes framework (I no affiliation with either). And that's great that there are such frameworks. It's not the job of the language developer to create the framework imho (e.g. CPAN does a great job supplementing Perl)

Re:Php in the enterprise? Scary thought.

[JimDabell]

Since its inception, PHP has gone from a simple website templating language and form processing tool, to a semi-OO scripting language hacked onto a bunch of C extensions, and now they expect to become a fully OO, enterprise-ready language?

Scary.

Scary? Projects evolve. Apache wasn't always "enterprise ready". FreeBSD wasn't always "enterprise ready". Just because something started out as a pet project rather than at a lab, that doesn't mean it's automatically "tainted" and cannot ever be useful to big businesses.

Libraries of code written in a templating language!

PHP may have started out as a templating language, but it is a general purpose scripting language now. You can even write GUI applications with it.

And what is it with all those PHP developers who seem to think a "class" is another term for "static function library"? The concept of using object types is foreign to thse people - they'd rather make huge monster arrays.

So the language is judged on its worst practitioners? If that is the case, then, judging all languages equally, we'd better just give up this programming lark and hide under a rock.

Rewrites of crufty code are not exclusive to PHP, you know. Neither are bad developers.

Smarty is a joke.

[neiras]

I'll say it again: Why would you write a templating language in PHP? Smarty fills a need that does not exist. The separation that needs to be there is between PHP code that affects layout, and PHP code that does stuff like writing to databases, processing forms, etc.

You don't need a "templating engine" to gain that separation. You need a standard, well understood way of organizing your PHP application, and some libraries of code to support that method of organization - that is, you need an application framework. And PHP sorely needs a *standard* one. It may not be the language developers's job to create it, but it would certainly boost PHP's image if they did - imagine the flood of nice, interoperable applications that would emerge!

CPAN is not a framework, it's a massive library of code libraries, same as PEAR on the PHP side. Code libraries are good, but they don't define a way of structuring your application.

Perhaps one of those frameworks you mention will become a standard, but as long as they implement 'templating languages' I'm not going to hold my breath. PHP may be going in the right direction with the new stuff in Zend 2, but it's still way off the mark for serious webapp development.