Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
The Internet

PHP4.0 beta released 96

Posted by Hemos from the fun-with-betas dept.
Emphyrio writes "Today, the first beta of Zend (php 4.0 scripting engine) was released. Php 4.0, in combination with the Zend scripting engine, is supposed to be a faster, more efficient, and enhanced version of php 3.0. Benchmarks between php 4.0/Zend and ASP have been made, giving _very_ good results, and showing php 4.0/Zend to outperform asp greatly. Php 4.0 is the first public php release using the Zend scripting engine, wich is relased under the QPL source license. More information about Zend and php 4.0 can be found on the Zend home page and the Php 4.0 homepage. . "
This discussion has been archived. No new comments can be posted.

PHP4.0 beta released More

PHP4.0 beta released

Comments Filter:

  • I can't remember the number of times I've done that. Just today I had a "sheeesh, this page is taking ages" moment again...
  • You are under no obligation to write bad code, and while PHP permits that, it does not require it.

    I agree with you that embedding executable code in your HTML is a bad idea, unless the executable content is small enough to be trivial. PHP does not REQUIRE you to embed large amounts of code directly in your page, however. If you follow sensible Object Oriented programming techniques, you can use PHP in much the same was as Java Server Pages uses JavaBeans.

    Put all of the complex code necessary for a single piece of functionality in a single PHP script which is built as a class. Pass the output of that class to a utility class, like an HtmlTable rendering class, and you only need to include a couple of PHP-specific lines in your HTML. At that point switching out the HTML becomes trivially simple. If you create a "style-free" HTML template which contains all the necessary PHP includes, then you can hand this template off to any HTML production person with simple instructions.

    You still have to include SOME PHP code in your HTML - enough to point to the objects that do all of the real work, and which provide HTML output.

    From the example you sited above, it sounds as though you hard-wired the PHP code into your HTML. This is a very common, but bad, practice, one which runs counter to component based development.

    The website www.phpbuilder.com [phpbuilder.com] has some good articles discussing the use of PHP classes.

    The practice of embedding executable content directly in an HTML document represents a way to share some of the development burden with people who may not be qualified programmers. You can create an object tailored to your immediate needs (business or otherwise), tell your HTML producing co-workers how to use that object on a web page, and let them do the rest of the work, while you go back to building more objects.

    If you follow this practice, the graphic designer doesn't have to give you HTML templates, you can give the designer your objects, and let them build the page. Tools like Macromedia's Dreamweaver allow you to define custom objects so that your HTML people don't need to leave their familiar environment in order to embed your functionality.
  • I don't quite see your point, since the existing scripting languages do offer similar features and more.

    But if you really want to have yet another template format:

    You can easily write a template paerser that accomplishes this, with servlets, with PHP or with mod_perl (for mod_perl, check http://perl.apache.org) and quite surely with all the other languages out there, too.

    I'd recommend having a look at mod_perl, since perl is usually faster when dealing with parsing text files.
  • disagree. major versions of important open source projects *are* "news for nerds stuff that matters". sure, you can read find them in freshmeat too, but you have to wade through 50 minor updates to random GUI CD players and the like. even if I don't use PHP (at the moment, anyway), I do want to have an idea where it's going, and the same goes for Mozilla and Zope and FreeBSD and other big projects.
  • I asked this same question when it was announced that GD would no longer be able to support GIFs.

    Rasmus, *the* PHP bloke, replied that it will still be supported because people use it, and most importantly, the fact that PHP is not distributing GD therefore there is no legal case against them. Nice !
  • PHP is faster, you don't need complicate benchmarks, just browse two similar sites one running PHP and one running ASP: The php one sends you the info inmediately, the ASP one takes a while and then responds. I know no beter benchmark than that.

    I have moved some sites from ASP to PHP and no client has ever complained about speed (their pages have been faster with PHP); and as a value-added product my clients no more have to reboot their machines twice a day.

    Now if PHP4 is (as they say) faster than php3 then Why not using it?
  • Are you on crack, or is it just me? PHP lets you *not* maintain a page as it's dynamic. I have several pages that are totally dynamically generated with php3 and a database. I go to a form, I enter text, it's updated, happy me. Pure HTML is great and all, but if the page is to change, php it.
  • The GPL was never meant to allow the original authors of the software to have any special rights over it. It's considered as a 'Copyleft' license, you're giving up all and any of your rights over the code, stating how it should be used afterwards. Moreover, the GPL is very restrictive, and would not allow PHP itself to be reused in commercial applications (since the GPL is 'contagious', if Zend was released under the GPL, so should PHP, and so should anything using it, which isn't what we want). The GPL simply isn't such a great license. It's good for many things, and bad for others. If you look around you, you'd find that great many opensource packages aren't released under the GPL, but under BSD derivatives or other opensource licenses. Ever looked at the Apache httpd license? Or MySQL's license?

    The QPL was designed to be an opensource license that retains the authors' copyright over the code, while letting everybody else use it for non commercial purposes. In our case, you can use it indirectly for commercial purposes through PHP or other opensource packages that may use it in the future, but you cannot use it directly in commercial applications. For that, you would have to talk to us (Andi&Zeev) first.

    That's exactly what we wanted the license to say, and we were happy to find a ready made, proof read license that is widely accepted by just about any opensource body in the world.
  • That's simply not true - you seem to be saying things without having any real knowledge about the serious differences between the GPL and the QPL. Even though they're both opensource licenses, they're very different from each other.

    Read my earlier reply at:
    http://slashdot.org/comments.pl?sid=99/07/20/125 8251&threshold=0&commentsort=0&mode=thread &pid=61#75

    About GDBM and other GNU software, this is very very minor annoyance. Building binary modules in future PHP 4.0 versions is going to be very easy, so distributing a pre-made GDBM module for PHP, under the GPL isn't going to be a problem at all.
  • That's no longer true for PHP 4.0.

  • Your link seems to be deader than the proverbial steel entryway affixation unit...can you check it and try again?

    Thanks for the other info, though! :-)

    TIA,

    Ethelred [surf.to]

  • Disclaimer: I'm just guessing here.

    Generally, open source licenses don't cover scripts/programs written in the OSS script/programming language. For example if you write a C prog and compile it with GCC, the input source does not become GPL'ed, and the output does not become GPL'ed either. As you pointed out PHP4 would be quite useless if the QPL didn't have the same 'idea' in mind. Most of the stuff in the QPL will apply to programs derived from the zend program source I guess.
  • PHP may have been /.ed earlier, but it looks as though zend.com is now. Can anyone enumerate the language enhancements mentioned, and anyone else give comments on their usefulness?

    Thanks,
    Gothland
  • In the GPL (as I understand it) you can code a commercial non-GPLed app as long as you don't distribute it. If you want to distribute it, you either have to GPL it, or cease using GPLed code.

    don't ask me to explain the QPL :) It sounds too complicated. Perl is a lot easier license wise though (given that the artistic license is really lax)
  • Now the php site is completely unavailable, and I guarantee you most of the people going there because of the slashdot story don't use php and are just going because they say it here.
    I for one have been waiting with bated breath for this release, and I am pleased as anything to have it announced on my favorite site. I do not wish to wade through freshmeat looking for things like this - I trust /. to give me the highlights, and this certainly qualifies.
    This is the domain of freshmeat and linuxapps, not slashdot.
    The Win32 PHP crowd would disagree - while it may be a linux app, it is by no means exclusively a linux app.

  • Comment removed based on user account deletion
  • AFAI understand it, those restrictions do only apply to modifications of the Zend engine, not to scripts in general. As far as you don't link with the Zope code, this shouldn't be a problem, if you apply the analogy to Qt. 'Linking' would probabably mean 'building compiled modules', which you could not distribute without source.

    One reason for choosing the QPL could be that the GPL is
    a) not compatible with (many) other Open Source licences and
    b) unlikely to be defensible in court.

    But, if you need a python-based web publishing environment, you could as well take Zope [zope.org]
  • Unforunately, I've already found some bugs in the date function

    I just fixed that in CVS.
  • The very same also applies to ASP, mod_perl/embed_perl, Java Server Pages and similar server side scripting languages. PHP is no better or worse in this particular aspect.

    You can use PHP for _very_ rapid development. This means putting all your scripting logic within the page. The result will be sloppy spaghetti code as described by you. (But if it's just a small job, you can have it finished in a very short time. Sometimes "good is good, but done is better". ;-)

    If you just discipline yourself, you put all your scripting logic outside the pages into include files. The dynamic page then only consists of some initial "require" calls to include the code and then, you can write your page just like a template, only with a few variable output commands in the page.

    So it depends on you _how_ you write code. I wouldn'nt call this "broken by design".

    There are *other* things that are bad about PHP3 though (I don't know about version 4, yet, so I hope that they have worked on that). Its standard collection of function libraries is not exactly elegant and the way PHP deals with hash variables also isn't really beautiful.

    IMHO, PHP is inferior and a less elegant language compared to Perl. But it is a *very* efficient tool to get the job done, even an idiot is able to install it on a web server (unlike mod_perl that takes a significant amount of time to tackle) and even non-programmers understand how the mixture of HTML and PHP code works.
  • I know of at least one site that went from a response time of 5seconds (ASP) to instantaneous (PHP). They switched web servers at the same time (iiS to Apache).

  • I fail to see what is so great about php (or mod_perl for that matter). Sure to makes it easy to do simple things but if you want to build a really great dynamic site Zope is the way to go. It includes a real programming language (Python), and you don't have to mix code and HTML. The licensing is better too. Check it out.

    http://www.zope.org/
  • Use Response.Flush() in ASP to send buffered output to browser as often as you want. You can output some static HTML and then do Response.Flush().
    But anyway, using Quicksort and empty loops for measuring performance is meaningless. I think more valid benchmark would be like outputting data from same databases to HTML - using best methods available in both platforms.
    And you should know that ASP is NOT a language like PHP/Zend - it's scripting host that can accept multiple languages - mixed in one file. You can use VBScript, JScript, PerlScript and any scripting engine you want easily.
  • 5000 milliseconds?. What they were doing in ASP?. My ASP apps would take so long only under a load of maybe 30-40 simultaneous requests!. And I'm talking about 3-4 database connections per page!.

    (Note: above approximation is for my laptop - K6 300Mhz, 64M RAM, NT 4.0 Wks)
  • Take a look at the QPL 1.0, there's still a patch clause.
  • In fact, the QPL is a pretty good license, if you like the GPL. It's essentially GPL plus right to link to all other Open source code minus right to do 'closed' in-house development.

    Now, I *like* the QPL, but...I wouldn't go that far.

    The GPL is the best license, bar none, because it is the *only* license that grants *equal* rights to all users *and* keeps software from becoming closed. No one has special rights. That is the only problem I have with the QPL: it grants special rights. Otherwise, it's a great license, and discourages closed software like the GPL.

    --

  • Well, looks like we have (more or less) 100% cross-platform scripting engine. Along with Java servlets, this could mean that the OS/hardware would be irrelevant, wich is a good thing(tm).
    Start your application on a lowly Pentium Linux machine, and upgrade to Sun Enterprises when you "make it" :)
    Jón

  • Why QPL? (Score:2)

    by Cee ( 22717 )
    Why release the software under the QPL and not the GPL. PHP3 is released under the GPL, so PHP4 has to be too. Which means GPL:d software will be linked with QPL:d... Aren't the licenses incompatible?
  • The announcement was up last night on PHP's home page, although I don't recall an announcement to the PHP mailing list. (Of course, I haven't been checking it as regularly these days. Both I and the list are swamped.)

    I'm pretty excited about the new benchmarks. I hope that the /. effect is indicative of interest in the tool: it's really a very intuitive environment. Not something you'd want to write system utilities in (although I'm told it's been done), but for scripting web pages, it's terrific. Check it out.
  • I'd like to see benchmarks comparing PHP3 or 4 with ASP, mod_perl, static HTML, SSI/xSSI, and so on--in other words, a definitive list of _all_ the major development platforms for websites.

    I'm wondering partly because I use PHP a lot, but know just about zilch about mod_perl and don't know if it's worth it to try using it. FWIW I use PHP mainly to make a global, dynamic template for a website, which then reacts to the browser type to generate code. Anybody know how PHP and mod_perl compare for that kind of use?

    Ethelred [surf.to]

  • There are lots of mirrors for php.net.
    But i have not found one with anything
    in the /version4 dir yet.
    Try .php.net

    http://fi.php.net/ for example

    I couldn't find any mirrors for zend.com from looking at the zone file either.
  • Since this morning (GMT), I can't access the PHP site. Is this a routing problem or is it unavailable for everyone ?

    If it's a routing problem please help me find a mirror 8)

    J-F Mammet
    webmaster@softgallery.com

  • Sick of Slashdot (Score:2)

    by Anonymous Coward
    WHY do you feel the need to post software release announcements? This is the domain of freshmeat and linuxapps, not slashdot.

    Now the php site is completely unavailable, and I guarantee you most of the people going there because of the slashdot story don't use php and are just going because they say it here.

    Meanwhile, the people who USE THIS SOFTWARE FOR A LIVING can't even get to the site.

    Gee, thanks slashdot.
  • PHP3 is released under the GPL, so PHP4 has to be too

    I was under the impression that the copyright holder can issue the source under whatever license they choose. Previous releases have no relevance. Of course, this only applies to the code which they own the copyright too. I'd assume that patches had been submitted to PHP 3.0 with other copyrights. This would complicate matters I guess.
  • Zend is a complete rewrite of the PHP scripting engine from scratch (IE: No code reuse).
  • According to http://www.php3.net/license.html [php3.net], "PHP is distributed under 2 licenses. You are free to choose whichever license suits your requirements best. The first is the traditional GNU GPL (General Public License) and the second is the PHP License."
  • OK, Joshua's gonna kill me for this, but check his stuff:

    Hello World Benchmarks [joshua.com]

    Note that this is for a very limited test - A simple "Hello World". The idea being to test the startup time and latency only. Obviously this doesn't test the speed of database interfaces, long scripts, loops, etc. We're trying to put that right now with a sort of competition between the different scripting environment people.

    For what it's worth, here's what Rasmus Lerdorf had to say about PHP4 vs mod_perl:

    > keep in mind that a short test like this plays into
    > PHP's strengths a bit. The larger and more complex the script is, the
    > more the gap between mod_perl and mod_php narrows performance-wise and at
    > some level of complexity mod_perl overtakes mod_php. With PHP4 this point
    > has been moved further out to the point where the script would have to be
    > *extremely* complex in order for the overall end-to-end request to come
    > out faster in mod_perl. But you always have tradeoffs. With PHP you
    > trade power and performance for really complex scripts for speed on simple
    > stuff. That also means that the two packages can be very complimentary
    > and be used together to get the best of both worlds.
    >
    > -Rasmus

    (Hope Rasmus doesn't mind me posting this here, but it's in the mod_perl archives anyway).

    - Look for new benchmarks using more real-world stuff coming soon.

    Matt.

    perl -e 'print scalar reverse q(\)-: ,hacker Perl another Just)'

  • Re:Sick of Slashdot (Score:3)

    by danimal; ( 64106 ) on Tuesday July 20, 1999 @03:56AM (#1794591)
    I am also a PHP developer and personally I think it is great if the PHP/ZEND sites are being /. (if indeed that is what happened). PHP has done very little, IMHO, to publicize itself. Most people know what ASP and Perl is, but very few (that I have run accross) people have ever heard of PHP.

    publicity => more users => more developers => better product

    The site will likely be available, as usuall, 8 hours from now. I have been chompin' at the bit for this release for months, a few more hours won't kill me.

    Relax a bit.

    DS
  • > One reason for choosing the QPL could be that the GPL is
    > a) not compatible with (many) other Open Source licences and
    > b) unlikely to be defensible in court.

    Could you please elaborate more on that? What makes you think the GPL is legally any more different than the other free licenses? I have not heard any convincing arguments so far ...
  • Just a thought...

    Slashdot is probably not the only place with a big fat link to http://www.php.net/version4 this morning. In fact, I've seen it three other places this morning, of the three sites I've visited.

    Just because the term is "slashdotted" doesn't indicate that an appearance on this site automatically equals a dead server.

    So chill. Or do you really need to deploy PHP4.0b1 before lunch?

  • Re:Sick of Slashdot (Score:1)

    by Anonymous Coward
    Yes! I must deploy it before lunch! The fate of the free world depends on it!

    :)
  • You're wrong :)

    The Zend license only concerns C software written
    around it. You can write and sell as many PHP
    scripts as you'd like without requesting
    permission from anyone!

    As a matter of fact, the PHP 4.0 license is much
    less restrictive than the original PHP 3.0 license
    was, and much less restrictive than the GPL.

    The QPL only allows us to license the Zend engine
    to commercial companies, and has no effect whatsoever on PHP 4.0 nor its users.
  • That's simply not true. You can use GDBM and any
    other GNU software with PHP 4.0, just as you could
    with PHP 3.0. Even if we tried, we could hardly
    mess up the PHP license that would prevent you
    from using GNU software with it.

    What's the effect then?

    The effect is that since PHP is no longer distributed under the GPL, but the PHP license, we can no longer distribute GNU software with it, in the same package. If you obtain the GNU software in other ways (e.g., ftping it from ftp.gnu.org; GDBM was never really distributed inside PHP anyway) - you're free to use the two packages as much as you'd like. PHP 4.0 supports GDBM just like its predecessors, and there are no legal issues involved in using this or any other GNU package with it.

    One last note - it is Zend that's distributed under the QPL, not PHP. PHP is distributed under the PHP license (which points you to the Zend license if you wish to see the license under which Zend's distributed).
    Simply put, end users of PHP (including site builders that sell their sites) should not be concerned in any way with the Zend license. It hardly has anything to do with them. The Zend license affects mostly two groups of people - people who publish patches for it, and commercial companies that wish to write applications (C applications, not PHP applications) around it.

    We'll publish a FAQ for the two licenses soon, because we see this is bothering people, when it really shouldn't.
  • Could you please elaborate more on that?

    OK. You asked for it :)

    One of the reasons TrollTech stated for not taking the GPL (+ an additional commercial license) was this legal aspect.
    RedHat stated this assumption as one of the main risks when they filed for the IPO.
    Many other companies and press reviewers mention that point.
    So this seems to be a valid concern. But why?

    The GPL is both long *and* unclear. It tries to be comprehensive and precise but fails miserably.
    Think of the discussions about the meaning of (the current version of) the GPL. Everyone disagrees with each other, and in the end the dispute is settled by asking RMS. So the GPL essentially means what RMS wants it to mean. This may be OK in a moral context, but it is insufficient for legal purposes.
    The main problems with the GPL v2:
    -> No clear vision of "linking" and "derived works": Todays software words sees much more kinds of dynamic cooperation between software objects than a couple of years ago. Plugin architectures, CORBA components, XML based GUI apps etc etc, make the distinction between derived/combined and independent works VERY tricky.
    -> The "system component" clause is extremely unclear. Who defines what's part of the system? What ISN'T part of the system, when distributors ship gigabytes of software with their "system"? This has to be clarified IN the license, not by the whim of its creator.
    -> "GPL compatibility": In short, a license is GPL compatible when RMS says so. Period. There are rules of thumb (more/less restrictive), but none of these are justified by the license text. If you like, I can give you very valid reasons why the X license is not GPL compatible...

    In short, lawyers, at least here in continental Europe, laught at you if you show them that peculiar license text (that's what I have been told). Caldera's and TrollTech's lawyers obviously felt the same.

    In fact, the QPL is a pretty good license, if you like the GPL. It's essentially GPL plus right to link to all other Open source code minus right to do 'closed' in-house development.

  • Mass bustage everywhere!!! (Score:3)

    by tgd ( 2822 ) on Tuesday July 20, 1999 @07:14AM (#1794599)
    Its like a train wreck. Stuck PHP4 on one of my testing servers, virtually none of the existing base of PHP3 code seems to work properly.

    Has anyone had much luck with it?

    Some code elements are obvious enough why they don't work. I'm not clear exactly why they would no longer allow non-static defaults to parameters in class constructors. Much of my code doesn't work because of that, but that can be (much less elegantly) fixed. They claim there's not very many situations where you'd want to do that, but I can think of dozens of them.

    Also, PHP4 doesn't seem to like returning instantiated objects from methods in a class. I'm not clear why it wouldn't allow that, but it craps out with a parse error. Its possible that error messages in PHP4/Zend suck, as well, since that particular one isn't a documented incompatability, and perhaps its saying the error is on that line when the error is in the parsing of constructor for the object being returned.

    (if that wasn't clear, code like this doesn't seem to work:)

    function my_function($var = "") {
    return new OtherObject ($this, $var);
    }

    Worked fine in PHP3. The error message sucks, so its not clear if the error is in the returning of the object, in the passing of my current object to the new object, or possibly in the constructor for the object.

    Has anyone done any serious OO coding in PHP3 and had it work cleanly in PHP4? I recognize that a lot of the OO functionality wasn't documented, and should've known it could be changed, but some of this stuff isn't rocket science, and works in most other OO languages.

    Anyway, good in concept, but looks like I'll be sticking to PHP3. I wonder how long development will continue on the PHP3 code base...
  • Your informatio about the Qt license is obsolete. The patchwork text isn't applicable to the QPL 1.0.
    CVS development is possible, and so is forking and changes in the code. The requirement to mark those changes clearly is the same as in the GPL.

    Actually the only "problem" with the QPL in Qt's case is not one of free software: It's the fact that shareware authors have a tougher life. That's why they are choosing LGPL'd libraries like fltk or gtk.
    In Zope's case it remains to be seen if there is a commercial license for proprietary modules, and how much it will be.

    Abd BTW, if you like python, there is Zope as well.

  • Now, while I know it's not the most efficient way to do things, you can still get a real gif (or jpg!) by way of external programs.

    For example, the web-tool for our application used gifs, which were fine, until GD started not compressing them - suddenly 160kb gifs for charts! Uuugh.

    The solution? Just use something like giftopnm temp.gif | cjpeg (or a one-step program if you've got one). Our graph.php3 now just puts a
    Header("Content-type: image/jpeg");
    at the top, and uses
    imagegif($im,"temp.gif"); passthru("giftopnm temp.gif | cjpeg");
    instead of
    imagegif($im);

    No problem! :)

  • The natural progression from code in html.. is, html in code... maybe you think thats even worse, but I think its the way things are going. (of course, store the html in databases and the code runs the website and uses the html bits like lego -- thats the way slashdot does it, with a few caches of pre-built pages for more speed).

    CPU is cheap. inflexibility is expensive. Headers and footers, hell, even page templates, are far from enough...

    This is actually why I dont much like PHP, because I want a programming language that can talk to everything and is good with strings, not html with codelets inside (be they java, javascript or PHP). I already know a good language.. perl.. and mod perl puts that in the server. So my website doesnt even have any html pages...

    On a dual processor 500 box, and mysql, a gig of ram, and some 10k scsi disks, for a measly $3000 total cost with linux, I could flood a T3 with that.. (unfortunately, I dont HAVE a T3... but you get the point).

    -Justin
  • I don't know. The server crapped out with "too many connections" on perhaps 10% of queries, although there was ample bandwidth.

    Big relief when they switched to PHP: zippy and stable. Haven't had an error since.
  • You want something not unlike XML I suppose (although I don't think XML objects can be defined directly as, say, data retrieval objects) but for the time being, can be inserted at the required location so that the PHP code can be separated from the HTML code reasonably well.
  • Considering PHP 4.0 is the most free PHP ever, forking PHP in general and calling the fork FreePHP in particular would both be pretty silly ideas. Apache is not GPL'd. Time to start FreeApache? There's open source beyond GPL. In fact, there's a LOT of open source beyond GPL. Try reading and understanding what's wrong with the GPL before you bash months and months of work conducted by the PHP and Zend development teams to bring you a very good opensource product for free. Consult http://www.php.net/version4/license-FAQ.php to understand why all the license concerns people have raised on slashdot are anywhere between baseless and pure myths.
  • Thanks, but I already tried all the php mirrors
    available with no luck. I only found some cvs directories somewhere.

    *SIGH*

    J-F Mammet
  • I'm a bit concerned about this passage in the QPL license they're using:

    6. You may develop application programs, reusable components and other
    software items that link with the original or modified versions of the
    Software. These items, when distributed, are subject to the following
    requirements:

    a. You must ensure that all recipients of machine-executable forms of
    these items are also able to receive and use the complete
    machine-readable source code to the items without any charge
    beyond the costs of data transfer.

    b. You must explicitly license all recipients of your items to use
    and re-distribute original and modified versions of the items in
    both machine-executable and source code forms. The recipients must
    be able to do so without any charges whatsoever, and they must be
    able to re-distribute to anyone they choose.


    c. If the items are not available to the general public, and the
    initial developer of the Software requests a copy of the items,
    then you must supply one.

    This seems like total B.S. to me, and such a radical departure from how PHP3 was licensed, to render PHP4/Zend completely useless in a commercial environment. It makes it seem like there may potentially be a liability if an ISP is using Zend on their server, and a customer develops extensions for their website and doesn't make them freely available. There also isn't a clear distinction made between binary extensions, and external libraries of functions written in PHP.

    Anyone else see this as a concern? Maybe its time to fork the PHP development, and get a similar engine to Zend distributed where that's not as significant an issue.

    Its my understanding with GPL I've got every right to code a commercial non-opensource package that utilizes its functionality, as long as I either do not distribute the GPL'd software, or use it embedded into the binary form of my program? (Like the new CodeWarrior for GNU package...)
  • I'm a bit concerned about this passage in the QPL license they're using:

    6. You may develop application programs, reusable components and other software items that link with the original or modified versions of the Software. These items, when distributed, are subject to the following requirements

    I'm not sure I see the problem, as the emphasized part of the quote from the license should make clear, the provisos only click in if you distribute what you've written. I suppose there could be a problem with the interpretation of "distributed", but the most natural reading to my ear (which counts for jack in a court of law, I know) is that it involves releasing the software in a format useable by others, and wouldn't be met by merely running the software on your own site.

    Anybody more familiar with the QPL want to weigh in?

  • We [CodeFab] have recently been approached by a couple of potential clients that were interested in porting away from PHP or were interested in starting new projects in PHP. Certainly, PHP has very recently arrived "on the radar" in the corporate world in a very big way.

    So, I decided to have a serious look at it...

    ...it seems fundamentally broken.

    The idea of putting *code* in *HTML* is just plain wrong! It increases maintenance costs tremendously-- there is no division between user interface and application logic!

    Example: Say I built a big old hairy PHP site... client wants to change the look/feel, but not the logic. Great-- graphic artist provides me with a bunch of new HTML mockups of the new look and feel.

    I now have to not only integrate the new look and feel, but I have to also integrate my old code and-- in some very likely cases-- potentially completely restructure the code!

    Maybe I missed something? I'm hoping I did.

    Specifically, does PHP support some kind of template that isolates the HTML from the supporting code?

    If not, there is no way I could recommend PHP to any of my clients.

    b.bum

  • Try FastTemplate, you can find the link in this aritcle:

    md

  • It increases maintenance costs tremendously--
    there is no division between user interface and application logic!

    So what ? Generally I use html with php included at the relevant points.

    To define a php area of code, the to close. Anything else is not parsed ( OK other tags, but lets not complicate things here).

    You can do clever stuff such as


    A bit of HTML



    Generally, yes I think you are missing somthing - don't diss it until you've at least tried it. It doesn't take long to set up (about 45 mins on Linux, about fifty on windows) and I guarantee you won't feel the same a week from now if you try it now.



  • This all depends on who writes the code. The best approach (and this applies also to ASP, which I think is superior despite non-real-world PHP vs ASP benchmarks) is to use an include files (like header and footer) which contain common HTML code.. sort of template and then write all the code inside one large ASP/PHP block and using Response.Write/php equivalent to write all HTML like (header.asp also includes lib.asp with all the functions):
    <%@ Language = JScript %>
    <!--#include file="header.asp"-->
    <%
    var conn = openConn()
    var rs = conn.Execute("select * from authors")
    while (!rs.EOF)
    {
    Response.Write(rs("FirstName") + " " + rs("LastName") + "<br>")
    }
    rs.Close()
    delete rs
    releaseConn(conn)
    %>
    <!--#include file="footer.asp"-->
     This means all outer HTML (e.g. headers, footers, menus, navigation etc.) is separate from inner code. HTH
  • so now that GD has gone from GIF to PNG...will PHP adopt a new image library? perhaps ILIB? the reason why i ask, is because i actually find the dynamic gif creation very useful. anybody know anything about this?
  • You can still use older versions of gd.

    You probably won't see Ilib support in the main distribution of PHP4 because it is licensed under the GPL. But PHP4 makes it much easier to distribute third-party extensions to PHP, which means we can stop putting everything and kitchen sink in the main distribution.

    Jim (jimw@php.net)

  • As someone else pointed out, PHP3 was dual-licensed, under the GPL and "yet another free license" (basically the Apache license plus a "written permission for commercial use" clause).

    PHP4 is available only under the PHP License v2, which is essentially the PHP License v1, minus the "written permission" clause, plus a reference to the fact that the Zend code is under a different license.

    The Zend code is under the QPL, and is something that PHP4 is dependent on. But it is a different body of code, with different owners.

    Jim (jimw@php.net)

  • Actually, it was the standard Apache mis-configuration of having MaxClients set too high, so the machine was swapping itself to death. This has since been rectified.

    Jim (jimw@php.net)

  • Why was this posted? Because it's a big deal, PHP is a great alternative to ASP+VBScript, and with Zend and the optimizer it's a whole bunch faster across the board too.

    However, if you rely on PHP for a living, that's great. But if you depend on Zend for a living, perhaps you shouldn't. Depending on Beta software and then complaining when it doesn't work or isn't available is just *stupid*.

    Incidentally the PHP site != the Zend site, and the PHP site *is* mirrored.
  • Its like a train wreck. Stuck PHP4 on one of my testing servers, virtually none of the existing base of PHP3 code seems to work properly.

    Has anyone had much luck with it?

    http://www.php.net/ has been running PHP4 for a week or two now, with no problems.

    Has anyone done any serious OO coding in PHP3 and had it work cleanly in PHP4? I recognize that a lot of the OO functionality wasn't documented, and should've known it could be changed, but some of this stuff isn't rocket science, and works in most other OO languages.

    This is a beta release. There may be simple things broken. In fact, there are probably lots of simple things broken.

    PHP is not an OO language. It has OO features. Right now they may not be as well-tested as you'd like, possibly because not many of the regular PHP developers rely on the OO features that heavily, particularly things that are the slightest bit exotic.

    Anyway, good in concept, but looks like I'll be sticking to PHP3. I wonder how long development will continue on the PHP3 code base...

    As long as there are people willing to maintain it. You certainly won't see it disappear before PHP4 is out of beta.

    Jim (jimw@php.net)

  • First, I want to thank everyone for the insightful and non-inflammatory replies. I will definitely research the links and think through an effective process for working PHP in more detail.

    I would also like to present what I think is an excellent model of for such an environment.

    In particular, a separation of HTML and code such that the HTML is simply standard HTML with, maybe, one or two additional tags. These tags would basically provide the binding between PHP and the underlying code. Example:

    PHP Name="MyDateThingy"/PHP

    Would expand the MyDateThingy PHP "object" or "function" and shove it into the HTML. Conditional HTML would be done by sticking the HTML "inside the tag". I.e. in between the >.... then, if MyDateThingy or, my appropriate, MySwitchThingy evaluated to true, then the HTML inside the tag would be emitted, otherwise not.

    This kind of a system separates the front end from the back end such that the front end can be edited with your various random standard HTML editors... UI change? No problem....

  • Gee... u gotta love how nobody questions the validity of PHP4's benchmarks.

    You guys almost sh@t yourself when you saw the NT bechmarks done by both Mindcraft (twice) and PC Week (once).

    Yet no one questions these? They are done by the company putting out the product... hrm.

    So here it is:

    Bitch bitch bitch, whine whine whine, bitch bitch bitch... this [place product here] sucks, it's obviously bullshit. There is no way that [place product here] could out do [place favorite under-dog OS/App here]. It was obviously swayed by the funding of [place company here] so they can't possibly be valid.

    There... somebody had to do it.

    If it's faster (considerably) then I will use it. (Athought I love ASP and it's extreme easy of use.)
  • *doh*... that'll teach me to post without a preview ;-) :

    To define a php area of code, the to close.
    Anything else is not parsed ( OK other tags, but lets not complicate things here).

    You can do clever stuff such as


    A bit of HTML



    And the bit of HTML will *only* be shown if the if statement is met. Nice !
  • Oops... There should be rs.MoveNext() inside the loop just after Response.Write
  • Correct me if I'm wrong, but then wouldn't the above prohibit the selling of php scripts to a general market?

    Say for instance, you create The World's Best Shopping Cart software. Wouldn't you then be forced to distribute the source code as well as a binary format?

    Also, many contracters do not as a habit "sell" the source code to their work when they do contract work for employers. Won't this QPL force them to hand over their code?

    We have the GPL which has worked fine for over a decade. There's zero reason that I can see to use this QPL.

  • You'd think that, if you depend on this for a *living*, you'd make sure you had a bit of failover protection to cover your ass should the main website -- over which you have no control -- ever go south. Do you whine every time its uplink has backbone trouble, too, or were you just posting to piss on slashdot?

    - A.P.
    --


    "One World, One Web, One Program" - Microsoft Promotional Ad

  • Lets try this again :

    To define a php area of code, the . Anything else is not parsed ( OK other tags, but lets not complicatethings here).

    You can do clever stuff such as

    A bit of HTML


    The html bit will only be shown if the if statement is met. Nice !
  • Perl, when used incorrectly, suffers from the same problem. The solution for complex scripts is to put the html code in templates just as you would in Perl. (See here [thewebmasters.net] for a fast templating package for Php.

    Keep in mind that this is a design decision: allowing you to put code in your html makes sense when all you want is one or two lines of script.

  • Read the php-dev mailing list archives.

Slashdot Top Deals

You can tune a piano, but you can't tuna fish. You can tune a filesystem, but you can't tuna fish. -- from the tunefs(8) man page

Close