Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
PHP Programming

PHP5 Co-Creator Interview 53

Posted by timothy from the are-you-going-to-disneyland dept.
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."
This discussion has been archived. No new comments can be posted.

PHP5 Co-Creator Interview More

PHP5 Co-Creator Interview

Comments Filter:

  • PHP's broken security model (Score:3, Interesting)

    by Mr. Darl McBride ( 704524 ) on Tuesday March 30, 2004 @07:59PM (#8720496)
    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.

    • Welp, time to start taking over websites on shared hosting companes.
    • 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
    • Eh, this is really outside the scope of PHP to fix; it's something for CGI suexec, FastCGI, Apache's perchild MPM, or some other higher level system for web based scripting to deal with.

      If you don't want to take PHP seriously, do so because of it's instability (and poor release engineering), it's lack of speed (which has been partially fixed several times, but hey; Zend need to make their money!), the complete mess it's extensions are in, the inflexibility of the language (again, partially dealt with in Ze
    • It is quite possible to make PHP very secure, it just takes decent coding and a lot of work. As for scripts being writable by other scripts, well the solution to that is to not allow any scripts other than a select set to be able to run and have none of them writeable, this is how I code for the medical industry.
    • 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/Gr
      • 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.
        I would venture to guess, and I doubt I'd be far off, that this "one particular situation" represents >90% of all potential php servers. It is absolutely insane to ignore this.
    • Ahhh... the search for the "perfect" language continues.

      No one language is going to work for everyone. Is PHP the most secure language? Definitely not. Is it one of the easiest to learn languages? Yes.

      Hind-sight is 20/20. I am sure that way back when PHP was created, had they known that such a ginormous percentage of websites on the Internet would be using it they might have done things differently. Who knows...

      PHP is so popular because it is easy to learn, supported by a massive, massive user base,
  • The idea of being able to manipulate store retrieve and execute on the fly is currently blowing my mind. I can't wait to get started on it. This is truly groundbreaking


    Bring on the Lang X has had that for years

    Yea, with a lot of lame hacks you could have done this with a file structure with php itself. But this sounds seamless.
    • Just to be clear, any language that can do dynamic evaluation has had this always. Language extentions to make it seamless is innovative but not groundbreaking - it's a cool idea thats rarely used enough that other languages haven't made a big deal out of it. I've used database-as-filesystem type deals that work on this concept for dynamic web pages and it's largely a nightmare to maintain.

  • Php in the enterprise? Scary thought. (Score:4, Insightful)

    by neiras ( 723124 ) on Tuesday March 30, 2004 @08:43PM (#8720834)
    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. (Score:5, Interesting)

      by wan-fu ( 746576 ) on Tuesday March 30, 2004 @08:55PM (#8720921)
      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)

      • Smarty is a joke. (Score:3, Insightful)

        by neiras ( 723124 )
        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 fra

      • 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.

        Here, here.

        I would agree that PHP needs some standard way of separating presentation code/html from code. Both JSP and ASP.NET do a good job of providing a standard mechanism to acheive this.

        The existence of Smarty shows the need and willingness of developers to use this kind of tool. However, skipping over the important point of whether Smart
    • well, there are several template kits for php. i'm not a fan of smarty coming from a perl world, so i ported html::template over to php. it's smaller than the one on sourceforge and about twice as fast. it's not extremely pretty, but it gets the job done and done well with a good execution time.

      it's really about peopel writing good code, much more than PHP providing an application framework.

      (http://www.robotholocaust.com/scripts/template. ph ps)
      • PHP is a templating language. That was its original purpose, and it's quite good at it. The problem is, it's now capable of a hell of a lot more than templating, and people get confused about how to use it properly. The PHP people need to clarify that, and a standard PHP web-app framework is the answer.

        A lot of well-meaning people have written templating layers for PHP to "separate layout from content". What they really need to do is separate layout-related PHP code (that's the stuff that generates HTML t

        • I suppose I can claim to be a PHP developer. 70% of the paid work Ive done in the last year has been with PHP. (I havent yet used Smarty). I use Perl for everything else, I have vaguly looked at the various Perl template systems. FWIW, I also once was a sysadmin at a ColdFusion shop, so am vaguly familer with that as well.

          PHP was "Personal home page". Just a stupid little template system. Now it is insanely complex. There is PHP-GTK+ bindings. Command line apps are being writen in it. Someone said "PHP nee

    • It entertains me that many of the arguments against PHP in the enterprise can be summed up as "well, it's possible to do it poorly."
      • I'm not saying it's not possible to write a reasonably high quality aplication in PHP. I'm just saying that PHP has to do better than a few syntactical differences and extension upgrades before it can even be seriously considered in the enterprise, where Java is the standard (for good reason). It's got a long way to go.

        If you don't agree, you've probably not had to work on a PHP site that gets thirty million hits a day, nor experienced the near-euphoria of moving to Java after dealing with that class A mes
    • i agree that php & bigtime enterprise software have
      nothing incommon at the time being.

      php has no business with enterprise software until it has no real security model nor a backward compatible language nor a threading model. not even thinking of application servers that interract on the language level like java's or sharing massive amount of data between threads so they would be synchronized and desynchronized as needed.

      php has a long way to go.
      i must admit that the php5 is a big step in the right dir
    • And what is it with all those PHP developers who seem to think a "class" is another term for "static function library"?

      Well, what would you expect from a procedural programmer? Incidentatally, these are also the kind of developers that would shun OO as unneccessary and illogical without taking the time to understand it.

    • Re:Php in the enterprise? Scary thought. (Score:4, Informative)

      by JimDabell ( 42870 ) on Wednesday March 31, 2004 @05:16AM (#8723502) Homepage

      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.

    • ...using n-tiered when it suits the domain (just finished a rather tasty J2EE system for a large client). Even a fairly complicated e-commerce engine can be done quickly and efficiently in PHP though if it's being done by someone who has years of "real programming" experience, not someone who comes along and hacks together a personal webpage or pet project (which invariably requies register_globals to be on, yuck).

      There is a framework out there that is proven, reliable and very easy to start using, it's
    • Your arguments are great but they apply for almost every lanugage I know of.

      As for frameworks look at apache. Have you seen how many frameworks it has for java? What about Swing, AWT, SWT etc? Just because they're are lots of frame works doesn't mean it bad.

      I agree with your class as a static function library but that's not PHP's fault. C++, Java and Perl have the same problem. When people learn C or VB first and then go to an OO langauge they generally get it wrong.

      As for bad projects I sure if yo

Slashdot Top Deals

Say "twenty-three-skiddoo" to logout.

Close