Slashdot Mirror

--

You might want to check out an effort to create a template engine for PHP written as PHP extension. See http://va.php.net/~andrei.

If you choose to go with some sort of PHP design / content seperation, you should know that PHP has dynamic image generation capabilities. PHP has documentation and webmonkey has a guide.

How about real standards like CORBA, OpenGL and PHP or PERL. What comes to sound OpenAL is very promising.
_________________________

Maybe if we had a few more details on the type of project you're working on we'd be able to better reccomend some stuff. You mention a web based project. Pyra might be a good one to take a look at. It lets you set up a tree like hierarchy assigning tasks to multiple users and set different permissions to modify items to different users. Pyra is in beta and I've had one glitch with it though. From Webapps comes ITeamWork and MediaLot. I haven't checked them out but they look promising. You might look at Zaplets. While heavily hyped, this looks a little too consumer oriented to me. The PHP Projects site mentions some task management systems. You could probably easily customise these to fit your needs. Zope might also be worth checking out if you want to customise something. Their Squishdot (Slashdot clone) is easy to set up and might be appropriate for your needs. And there might be other more appropriate Zope modules available for project management.

• Open Source the Chilisoft ASP Package
• Offer PHP *supported* & *out of the box*

For those who have been following the development of php one answer to the question is obvious. Modularisation of additional features allows zend to decide exactly which features of the project they wish to gpl and which they would rather commercialise. It remains to be seen whether this amalgomy of open source and commercial principles will be popular among those consumers for whom open source is becoming a way of life.
--

Why is this technique so useful compared to session-id tracking? I don't believe that it really is, or why such a fuss should be kicked up about it :

If I understand it correctly, it simply replaces the session ID normally stored in as a cookie/get-var in the hostname.

This would lead to extremely user-unfriendly domain names, and surely it would really bugger up users trying to bookmark the site (stale sessions could stay in bookmarks for a LONG time).

Also, its simply not as efficient as session IDs, which after one unfriendly GET, tend to store their results in a cookie which is transparently passed around. Surely dynamic DNS would all have to have really low TTLs and generally slow down site access if you have to do a large number of DNS lookups (which can be the slowest stage in an http access cycle?)

As I see it, the only problem with the session-id method is that it complicates serverside scripting, but with simply superb tools like PHPLIB all those details are abstracted away from the user. And also PHP4 has built in session handling to simplify things further. IIS has similar modules for ASP developers, and I'm sure others exist forother scripting languages (mod_perl? dunno ...)

So while this might be of interest to some specific applications, I can't see it revolutionising the whole ecommerce industry with its cunning "new" user tracking system.

But then again, I might be talking bull :) Do correct my bullshit if it is that, please.

1. Php Pros:
   1. Easy to learn. Once Apache is configured with Php, it is seductively easy to write code.
   2. The Db connection pooling comes in handy.
   Cons:
   1. It is yet another language (I mean, I already know perl, right? Why do I have to learn another language?).
   2. Also, you tend to design page by page. it does not have a great library system to use. It has lots of code snippets you can copy.
   Notable sites: Sourceforge.net, and persiankitty.com (reputed to be the yahoo of porn))
2. mod_perl: This beast can be used in several ways. If you use it with Apache::Registry, y use Php,ou almost are doing a disservice to yourself. The three ways of using it are:
   1. embperl: Looks like Php style of embedding. Comes preconfigured with DBI and friends. But, too cumbersome to programs. It also does not encourage component programming. It provides the substrate for you to build other features you might like.
   2. mason: Has cool component features. Has neat features such as caching with intesting way of managing it, and autohandlers. Looks ideal for the publishing world, where it evolved. On the cons side, not too many components.
   3. Apache::ASP: Not used it much.
   Notable sites: dejanews uses embperl. techweb, stamps.com use mason.
3. Zope: Too different from others. The strongest suite is the built-in authorization systems and web based management system. You can program at embedded HTML level called DTML, or you can write python classes. There are several prebuild modules that run out of the box. As long as the prebuilt modules serve you well, you can go ahead and use zope. Otherwise, be prepared for a long learning curve. It almost looks black magic to me.

   As an aside, python has the weirdest variable scoping and declaration rules. I ought to know, I have a PhD in programming languages.

4. ACS: ACS is entirely different from others. It is not a language like Php, it is not a webserver like APache, it is not a app server like zope. What it is one man' use Php,s vision and experience about community web sites distilled into a toolkit. It is a datamodel, it is a set of practices, and a set of programs. It happens to use TCL, Oracle, and Unix. But that is almost besides the point.

   The biggest selling points of ACS for me are:

   1. The documentation. Quite possibly the best documented system. I can take an average joe out of the street and train him to use ACS in a systematic way in no time.
   2. The Data model. I would expect to pay in hundreds of thousands of dollars for such a datamodel. It constantly amazes me to find the little details that I needed in those datamodel.
   3. Best practices to run a website. How to harden a Unix system and set up the services so that you can sleep peacefully.
   The negative points are:
   1. Alas, it requires Oracle. I just learnt the existence of ACS/pg and I am rejoicing!
   2. Not too wide spread usage. I expect this situation would change. Look at this way. I tried building a community web site. It took me untold hours to gather all the snippets of information for a Php based site. It took me no time at all to build it using ACS. I would use ACS for a community based website over any other toolkit anyday.
   3. No good enough template mechanism. Fortunately, ADP in AOLServer is changing that.
   So, in conclusion, php and modperl and zope vs ACS is not a right question. You can implement ACS in php, and I frankly hope somebody does to save lot of human misery and suffering.

   Rama Kanneganti

For case 1, let's assume complete a complete linux front to back solution, with as much free (or mostly free) software as possible:

Needed Software Components:

1. Favourite Distro of Linux
2. MySQL or Postgres Database (personal pref is for MySQL... not going to get into the pros and cons here...)
3. Dynaminc Web-Scripting Language (PHP, Perl, whatever... personal pref for this kind of thing is PHP... again, I'm not debating at the moment...)
4. Linux Vitrual Server Project - very solid load-balancing from my experience. Don't know how it compares with the appliances on the market... but it's still solid.
5. HA/Redundancy software (Linux HA project isn't quite there... but they're getting close... there are some commercial packages available - one that's free for non-profit use - http://www.high-availability.com

Hardware:

NB: For maximum up-time I recommend systems with redundant hardware (backup power supplies, dual NICs, and RAID arrays)

1. Firewall/Load-balancer - preferably using HA/Redundancy software on two machines... Mirrored (RAID 1, right?) boot/system hot-plug drives are a good idea.
2. Web-farm - up to X systems (where X+1 breaks your budget... ;) ) load balanced with Virtual Server Project. For a reasonably heavy duty method of doing this relatively cheaply, see Cubix and their "density" series... up to 8 servers in a single box... with hot plug everything. RAID isn't as necessary here... as the systems themselves are effective your RAID...
3. Database system - again preferably an HA/Redundancy cluster for maximum availability. I recommend a mirrored boot/system disk again, with a RAID 5 array (or RAID 5+5 - mirrored RAID arrays) for speed and maximum availability... highest RPM drives you can afford can help here a lot for speed, too.
4. 100 BaseT Switch for maximum through-put. Personal preference is for Cisco but your budget dollars may vary.
5. I've mentioned RAID a couple of times... you can get SCSI and IDE raid these days (SCSI being more common)... the cheapest/fastest one I've see is from Raidzone - very nice, check them out (up to 15 - 40 GIG hot-plug IDE drives in one array, with a very high through-put). You can also do software RAID, taking a performance hit, but saving coin...

Case 2 assumes that you don't mind using some commercial stuff... and have a bigger budget:

1. Replace Virtual Server with an appliance. (Alteon, F5 and Cisco all make good products... presently my preference is with F5's BigIP.
2. Replace in born Linux firewall with Checkpoint's firewall-1 running under linux - or an appliance firewall, a Cisco PIX is very nice, and has very high though-put. The Nokia appliance running Checkpoint and a BSD bastardisation is quite nice.

PHP, freely availble from php.net is a Pre-Hypertext-Processor (Hence the name.) It is similar to ASP in the fact that you splice snippets of code into HTML, but thats where the similarities stop. I used to do full time ASP backend development for the web design company I work for (no, not digital11 for those of you who like to criticize my page.) I was looking for something that was totally server compatible for pretty much everything, because our client's hosting methods vary between OS's. Once I found PHP, I never looked back. Its faster, its easier to learn, its easier to use, its faster, it has many more features, its open source, its faster. Now I haven't heard about web objects (oh, did I mention that PHP is faster?) But after using PHP, I'm sure it would have to do everything but fsck your wife for you to be better than PHP.

d11

The latest version of php- Version 4 - uses the zend engine. Zend has an optomizer and a cacheing option. I've used php3 and I am pretty happy with it. php4 is still in beta, but its almost done.

I hope this helps.



john

Before I forget.

• PHP link
• MySQL link

Another important feature is that these techniques are server side so are independent of the browser used. You can also use PHP with Oracle 8i but most of the really cool stuff is centered around MySQL. Plus, why spend money on software if you don't have to. Spend the money save paying for support or donating to the OpenSource projects (PHP and MySQL). Yet another advantage is that the application can be developed and tested on Windows (read Configuring Windows98 For Local Dev) then uploaded to the Apache Server. A good free program with PHP syntax highlighting and tons of other goodies for developing is HTML-Kit.

Also caught the talks on PHP and samba, very interesting. If you want a glimpse at the PHP presentation take a geeze at http://www.php.net/oz/

There is even a webcam at the SuSE stand during show hours (I hope this doesn't kill their iffy net connection) http://suse.secret.com.au

The debian guys would have won the biggest slobs of the show award ;), stuff all over the place, sucking on illegaly imported caffeinated mints - Rob being one of them (didn't realise it was him).

I was even prepared to run around with a turbolinux tattoo on my forehead in exchange for a fluffy penguin but they were out by the time i got there (penguins no tatoos). They were more than willing to make an exception for me (off me?) and give me the forehead tattoo anyway. The icecream was nice tho, as was the free donut and coffee from another stand, I guess that explained the police attending the show.

Hear, hear... I repeated the same thing somewhere else on this discussion and a coupla older ones: we need to clean up the config files mess. And I even would go one further: clean up man files as well. Man files are an anachronism; they are not hypertext --no links-- and are not easily searchable. When every machine has a browser builtin, why are we still dealing with man files? Let's move manuals to some SGML/XML/HTML based format, that can be viewed through a browser and make 'man' a parser of that format for the old folk.

You could then even import annotations and errata on the documentation from the Net... look at how the PHP folk do their manual. It's the future of documentation folks...

But this is Open Source... let's stop bitching and day-dreaming; sit down and write code... who's hosting the CVS? ;-)...


engineers never lie; we just approximate the truth.

I built the dtheatre.com code with Killbot up there and I was a firm believer in Perl some one would ask me to check the time I would make a perl script to do it.. but now I have converted all the way to PHP3 (PHP.NET) I still use perl for NT based sites and for some basic scripts like say a news headline grabber etc and it has far better regular expressions than anyone else.. but for everything else there's PHP3

There's already PHP - a crossplatform alternative to ASP. Why not help them instead of starting all over, using a Pascal-ish language (ugh)? Because of the money?

(PHP started supporting Windows in version 2, some time back, so it's probably not within the timeframe for consideration here. (This is "most improved" in the last year or so, yes?) Mozilla, of course, always had the goal of multiple platform support.)

That having been said, the decision to drop that much code and start fresh is a bold one, and The Right Thing To Do in a project where quality is more important than time, so I'm not trying to dis Mozilla here. :)

And none of this would have been possible without the pioneers who blazed the path towards open source within IBM with contributions like Jikes.

I gave up on waiting for a Slash release. I was looking for a similar /.-like engine for my site, and after some research I settled on PHPSlash. It's at least a generation behind /. --no user accts, no dynamic homepages, no moderation-- but: a) it's Open Source, with a decent enough following, b) it's based on PHP, which I wanted to learn.

FYI, there's also Squishdot (sorry no link in my RAM ;-) based on Zope and a coupla interesting projects on the Java Apache pages.

I agree with the other comments though. The /. overlords should be releasing Slash, even as a rough draft, just so to put their code where their mouths are.

engineers never lie; we just approximate the truth.

2) Tools and a development environment to access coporate databases. Data is the life blood of business. MS makes it easy for developers to get at databases. Linux does not. Not surprisingly MS has made COM objects to access all sorts of databases (I am not talking about the silly data control here either).

Right now PHP and, to a smaller extent Zope, are leading the way to dbms access. And it's not just for the Web, either. PHP is more than able to be a standard application scripting langauge capable of performing the duties of a number of previously entrenched languages/tools. You'd be downright shocked by the number of SysAdmins who are changing their perl scripts over to PHP.

For Internet B2B applications, PHP is very hard to beat.

---

The results of the vote can be found at http://il.php.net/vote_listing.php3.

It's about the content, stupid Ultimately, the growth and popularity of your site is determined by the quality of its content, not its looks.

What a very Slashdot thing to say.

It's a balance. The information has to be accessible to people. That can only be done through good user interface. And note that sometimes the looks _are_ the content. It depends on the purpose of the site.


Test with Lynx and make sure it provides an adequate (though not wonderful) user experience, then it'll likely work for everyone else.

Oh no. Not Lynx. Help! Next you'll want to make sure the site works on mobile phones. :)

Engineers try to create very focussed products that solve specific needs well, marketing tries to broaden the product's appeal, overloading it with features that end up satisfying no-one. Start broadening your appeal only after you've created a solid user base.

I completely agree with this. Amazon followed this philosophy perfectly.


Platform The underlying platform is irrelevent, in both security and performance. You should strongly consider PERL for dynamic content, only because it is the most used

Good reasoning. Windows is also the most widely used, you should go with that as well. There are better options

- Scott

------
Scott Stevenson

moo.

ok...in the linuxpower article, in the question regarding the differences between php3 and php4 licencing, one of the developers states:

"The PHP license used for PHP 4 is actually less restrictive than the PHP 3 license. In PHP 3, commercial companies had to get written permission from us in case they wanted to distribute PHP 3 with their product, we have completely removed this clause from PHP 4."

on the main page of www.php.net, it says:

"You can use it for commercial and/or non-commercial use all you want."

yet, http://www.php.net/license.html says:

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. If you wish to include PHP in a commercial product for resale, the PHP license permits it as long as the stated conditions are met.

further investigation of the aformentioned "PHP Licence" indeed shows that permission from the development team is required to include PHP in "...larger works derived from, or which bundle PHP..."

im wondering how a piece of software can be distributed under two licences, where one is the GPL which doesnt explicitly mention anything about companion licences?

ok, forgive me if this has been adressed, or if ive missed something thats blatently obvious. im not trying to dis anyone or point fingers or anything...im just trying to quench my non-lawyer curiosity.

--Siva

Keyboard not found.

moo.

ok...in the linuxpower article, in the question regarding the differences between php3 and php4 licencing, one of the developers states:

"The PHP license used for PHP 4 is actually less restrictive than the PHP 3 license. In PHP 3, commercial companies had to get written permission from us in case they wanted to distribute PHP 3 with their product, we have completely removed this clause from PHP 4."

on the main page of www.php.net, it says:

"You can use it for commercial and/or non-commercial use all you want."

yet, http://www.php.net/license.html says:

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. If you wish to include PHP in a commercial product for resale, the PHP license permits it as long as the stated conditions are met.

further investigation of the aformentioned "PHP Licence" indeed shows that permission from the development team is required to include PHP in "...larger works derived from, or which bundle PHP..."

im wondering how a piece of software can be distributed under two licences, where one is the GPL which doesnt explicitly mention anything about companion licences?

ok, forgive me if this has been adressed, or if ive missed something thats blatently obvious. im not trying to dis anyone or point fingers or anything...im just trying to quench my non-lawyer curiosity.

--Siva

Keyboard not found.

Well, you wouldn't be able to "convert" your forms, per se, but if you want simple database access for your system, I highly recommend PHP. They have some nice tools for database connectivity with many easy-to-use APIs.

While Perl is far better for parsing and regular expressions PHP3 is much nicer and closer to C than perl also it is a server side languague which makes it noticably faster and the database intergration is great compare it to the database intergration of Cold Fusion.

But I am not the only one that thinks that this is a great languague the estimated amount of servers using PHP should hit 1,000,000 this November which is a dramatic increase from the less than 80,000 when I started using it June 1998.

Conclusion: Don't stop using Perl but use PHP3 as well you will find them both usefull for different situations, if you visit dtheatre.com a good 20%+ of the first page is Perl generated and the rest is PHP3.
-------------------------------------------

Perl does a lot of things well. A lot of things do specific things that Perl does better.

Reasons why Perl is dominant:

• It's good enough
• Everyone knows it
• It's very well documented
• It's easy to pick up
• It's powerful once you get to know it
• It's a bit like C, only nicer

Using C or C++ for CGI scripts will not give you the performance gains you might think. We are no longer talking about mega-applications which are highly CPU-bound. This goes double if you make sensible use of the built-in functions in Perl, which are themselves written in C.

Rather, you are more likely to come across one of these bottlenecks:

• Forking a process or two for every single web request
• Disk I/O
• Network I/O

In real life that means: the amount of runtime that could be saved by writing the script in a compiled language is dwarfed by other factors - notably the effort of context-switching an entire program in and out every time the script is called. This is a fundamental problem with CGI, and a big one if you want all or most of your site to be dynamic.

So where do you turn from here? Well, chuck CGI and build the scripting language into the web server. This isn't as painful as it sounds. The obvious one is mod_perl for Apache - but Perl, though cool, is BIG and you do not necessarily want a half dozen copies of it resident in memory at all times.

My favorites - and I use these all the time these days, are:

• PHP if I have to run Apache
• AOLserver if I don't

Don't be put off by the name! AOLserver used to be called Naviserver, until the company was bought out by you-know-who. It's a rock-solid web server that I've been using it for years. Its embedded scripting language is Tcl, which is not fun to debug, but is extremely elegant once you are used to it.

There are others, but speaking from my own experience these two have allowed me to turn entire sites dynamic that would not otherwise have been possible - usually hobby sites that are running on old and donated hardware.

Dave

--

...when the Web took off back in '95 or abouts, Perl was a robust, well-understood language with tons of ready, freely available scripts to process enormous amounts of text. And since HTTP is text-centric, it was a natural first choice for CGI implementations. But I doubt it is any longer.

The Web and the technologies around it have matured enough to enable us to use custom-made tools for Web applications. For straight Web-only applications I'd go with the very impressive PHP4. For deployments that need to be tied in to a larger infrastructure (DBs, legacy code, uncoventional hardware), my personal choice would be the Apache Java Tools. Apache JServ, Apache Cocoon, and soon, Apache Jakarta should cover all your needs.

Both PHP4 and Apache Java have session management, pre-compilation to portable byte code, platform independence, and work well with most popular DBs (JDBC covers more of them though).

YMMV. As one of my ole engineering profs says: "50% of successful engineering is picking the right tool for the job" or something like that ;-)

n

I think perl is not easy at all ... those string-manipulating scares most newbies. (Regular expressions ? what the hell is that ? :) I think (IMNSHO:) that PHP is a lot better. It is a mix between Basic and c++. The best argument PRO perl is, that it runs nearly anywhere, and is installed on most webservers. PHP is easier, faster, less memory-intensive, and will soon be compileable to some p-code. (PHB's just LOVE that feature ! Most of them hate the Idea of selling your source code :) Check it out at http://www.php.net

According to the Apache Module Report at E-Soft Inc, PHP is more widespread than Perl as an Apache Module. These figures at www.php.net might be interesting as well...

We currently have the following on our Intranet.
Web based email - IMP
Global address book - Openldap
Search engine - htdig
Discussion groups - Hypernews

PHP and Apache will need to be installed to get things going.

You can view M$Word documnets with mswordview which is installed with IMP.

A lot of what you may need is on SuSe 6.2 which may make it easier to be sure that the right libraries etc exist

Best of luck to ya'.

//Johan

The "V" GUI applications framework is something that has interested me for some time (although, admittedly, I haven't put any effort into learning it -- PHP3 is keeping me busy enough these days). It allows you to write your application to one GUI API, and have it port very easily between X, Win16, Win32, and possibly Mac as well.

"V" is under the GPL, too...perhaps some interested coders could look into extending it to support your choice of widget libraries and other GUI environments.

Check out the homepage for more information

I think they are. Check out this CERT advisory, as well as this page from the php manual. It's certainly possible to set up a host like this guy is suggesting.. but some care needs to be taken. I'm not familiar with IIS, so I can't comment on the availability of a chroot()-style environment.

Also, ODBC support is not new to PHP 4. It was in PHP 3 as well and it hasn't changed much.

Okay, you caught me on this one - I went back and looked, and there is indeed support for an ODBC driver manager in php3. :}

About your comment that php4 is open source... I quote the php4 License FAQ Second, the license prevents commercial use of the Zend library to build commercial applications. Correct me if I'm wrong.. but that sounds an aweful lot like a violation of OSD rule #1. See this link for the full monty.

--

I think they are. Check out this CERT advisory, as well as this page from the php manual. It's certainly possible to set up a host like this guy is suggesting.. but some care needs to be taken. I'm not familiar with IIS, so I can't comment on the availability of a chroot()-style environment.

Also, ODBC support is not new to PHP 4. It was in PHP 3 as well and it hasn't changed much.

Okay, you caught me on this one - I went back and looked, and there is indeed support for an ODBC driver manager in php3. :}

About your comment that php4 is open source... I quote the php4 License FAQ Second, the license prevents commercial use of the Zend library to build commercial applications. Correct me if I'm wrong.. but that sounds an aweful lot like a violation of OSD rule #1. See this link for the full monty.

--

Ah, I forgot to mention: WDDX is supported on PHP, too. You can exchange data in WDDX format between PHP and CF without problems. PHP also makes good use of the expat XML parser that comes with your Apache or is available separately, enabling you do decode and perform XML RPC.

Ah, I forgot to mention: WDDX is supported on PHP, too. You can exchange data in WDDX format between PHP and CF without problems. PHP also makes good use of the expat XML parser that comes with your Apache or is available separately, enabling you do decode and perform XML RPC.

Let me try to clarify the 'bad' things:

- Really poor regex matching/replacing operations (should be as close to Perl as possible)

The PCRE extension does Perl-like regexes. See the manual.

- Poor loop functions (no 'next', or 'last')

PHP3 has supported these since the beginning. For example, to loop over the associative array $a:

for(reset($a); $key = key($a); next($a)) {
echo "current key is $key\n";
}

See the array reference of the PHP manual.

- cant assign variables like ($hi, $there) = 1, 3

Well, not that way. For example:

list($hi, $there) = array(1, 3);

This is also covered in the array reference.

As you mentioned, session support is integrated into PHP4.

Let me try to clarify the 'bad' things:

- Really poor regex matching/replacing operations (should be as close to Perl as possible)

The PCRE extension does Perl-like regexes. See the manual.

- Poor loop functions (no 'next', or 'last')

PHP3 has supported these since the beginning. For example, to loop over the associative array $a:

for(reset($a); $key = key($a); next($a)) {
echo "current key is $key\n";
}

See the array reference of the PHP manual.

- cant assign variables like ($hi, $there) = 1, 3

Well, not that way. For example:

list($hi, $there) = array(1, 3);

This is also covered in the array reference.

As you mentioned, session support is integrated into PHP4.

We are currently using Solaris as a server platform, with Apache or phttpd as a webserver and we are using Oracle and MySQL as databases. We are running PHP as scriping engine as CGI version and as Apache module in some instances.

You seem to come from a mostly Microsoft background, which is not where PHP is at home. PHP3 does not run as an IIS module, as far as I know, but only as a CGI version. This will make it perform much worse that for example CF or ASP on IIS, due to the abysmal performance of the NT platform and IIS as a CGI host - NT just doesn't fork. PHP4 will be running as an IIS module, but is in beta now and I would not build any production code on it - yet. As soon as PHP4 proves to be stable under load, it should outperform PHP3 by a factor of 5-10, though, plus the speed gain coming from being able to use it as a module on IIS.

On a Unix system (Linux, Solaris, doesn't matter) with Apache, PHP3 performs excellently as a module and can take any reasonable amount of load, provided you have enough RAM. We already know this from the Mindcraft benchmark - Apache must not swap and you must tune your MaxClients to match your RAM size to avoid performance degradation under high load. Many sites are parsing all pages, including their regular HTML, through PHP3 for convenience and the performance overhead is neglegible - if Apache can take it, Apache and mod_php can usually take it as well.

PHP excels in portability, support and in connectivity when benchmarked against CF. PHP will run on any old server platform and will talk to almost anything, and natively, where CF will most probably talk through an ODBC adapter. PHP includes some 10+ native database interfaces, including all major database vendors, and does LDAP, SNMP, SMTP, NNTP, IMAP4, POP3, some OODB and fulltext database protocols, can generate pictures on the fly, can generate PDF on the fly and so on. Writing extensions for PHP is trivial, if you can do reasonable PHP programming.

One point must not be left out of the equation when talking about PHP, and that is the online support. There are many large PHP mailing lists, including THE PHP3 mailing list, which are extremely friendly and efficient and usually generate correct and useful answers within 15 minutes. Also, the annotated online manual is a unique ressource for help, because it is learning and growing, incorporating user annotations. I have nowhere experienced anything that comes close to this kind in support, commerical or not.

My recommendation: PHP on IIS on Windows works, but will most likely not perform as exspected. It is nice for testing, but I won't go productive in this configuration. PHP on Apache on Windows works better, but will still not use PHP to it's fullest advantage. Also, you will make installation and maintentance unnecessarily difficult for you. PHP on Apache on any Unix will perform extremely satisfactorily, generate only minimal TCO, and is supported excellently. If you have at least minimal Unix knowhow inhouse, I suggest that you go for the full plunge in a test installation instead of an incremental migratory approach, because this way you will maximize the advantages of PHP and your server platform.

Re the migration from version 3 to version 4: PHP4 and PHP3 are drop-in compatible. There is no need to "port" from 3 to 4, because both languages are virtually identical. The differences are extremely minimal and well documented, also the development team is working on closing these final gaps between versions. Changes between version 3 and 4 are completly internal, switching from a fully interpreted system to a byte-code compiler/interpreter hybrid for speed reasons. Also, some language features have been added in an upward compatible and transparent way. We have tested the beta and found it to be living up to its promises in speed _and_ compatibility. Waiting for PHP4 won't pay: You can use PHP3 to learn just now and all this knowledge as well as your code will be valid and valueable on PHP4.

If you'll be using the CGI version of PHP3, please be sure that you

• set up a chroot() running environment for your CGI (phttpd does this by default, Apache does this with a modified suexec - ask me if you need it).
• compile a version of PHP with --enable-force-cgi-redirect or you'll be opening a great security hole.

If you have any further questions, please subscribe to the php3@lists.php.net mailing list or have a look at the PHP Knowledge base. These are great ressources.

We are currently using Solaris as a server platform, with Apache or phttpd as a webserver and we are using Oracle and MySQL as databases. We are running PHP as scriping engine as CGI version and as Apache module in some instances.

You seem to come from a mostly Microsoft background, which is not where PHP is at home. PHP3 does not run as an IIS module, as far as I know, but only as a CGI version. This will make it perform much worse that for example CF or ASP on IIS, due to the abysmal performance of the NT platform and IIS as a CGI host - NT just doesn't fork. PHP4 will be running as an IIS module, but is in beta now and I would not build any production code on it - yet. As soon as PHP4 proves to be stable under load, it should outperform PHP3 by a factor of 5-10, though, plus the speed gain coming from being able to use it as a module on IIS.

On a Unix system (Linux, Solaris, doesn't matter) with Apache, PHP3 performs excellently as a module and can take any reasonable amount of load, provided you have enough RAM. We already know this from the Mindcraft benchmark - Apache must not swap and you must tune your MaxClients to match your RAM size to avoid performance degradation under high load. Many sites are parsing all pages, including their regular HTML, through PHP3 for convenience and the performance overhead is neglegible - if Apache can take it, Apache and mod_php can usually take it as well.

PHP excels in portability, support and in connectivity when benchmarked against CF. PHP will run on any old server platform and will talk to almost anything, and natively, where CF will most probably talk through an ODBC adapter. PHP includes some 10+ native database interfaces, including all major database vendors, and does LDAP, SNMP, SMTP, NNTP, IMAP4, POP3, some OODB and fulltext database protocols, can generate pictures on the fly, can generate PDF on the fly and so on. Writing extensions for PHP is trivial, if you can do reasonable PHP programming.

One point must not be left out of the equation when talking about PHP, and that is the online support. There are many large PHP mailing lists, including THE PHP3 mailing list, which are extremely friendly and efficient and usually generate correct and useful answers within 15 minutes. Also, the annotated online manual is a unique ressource for help, because it is learning and growing, incorporating user annotations. I have nowhere experienced anything that comes close to this kind in support, commerical or not.

My recommendation: PHP on IIS on Windows works, but will most likely not perform as exspected. It is nice for testing, but I won't go productive in this configuration. PHP on Apache on Windows works better, but will still not use PHP to it's fullest advantage. Also, you will make installation and maintentance unnecessarily difficult for you. PHP on Apache on any Unix will perform extremely satisfactorily, generate only minimal TCO, and is supported excellently. If you have at least minimal Unix knowhow inhouse, I suggest that you go for the full plunge in a test installation instead of an incremental migratory approach, because this way you will maximize the advantages of PHP and your server platform.

Re the migration from version 3 to version 4: PHP4 and PHP3 are drop-in compatible. There is no need to "port" from 3 to 4, because both languages are virtually identical. The differences are extremely minimal and well documented, also the development team is working on closing these final gaps between versions. Changes between version 3 and 4 are completly internal, switching from a fully interpreted system to a byte-code compiler/interpreter hybrid for speed reasons. Also, some language features have been added in an upward compatible and transparent way. We have tested the beta and found it to be living up to its promises in speed _and_ compatibility. Waiting for PHP4 won't pay: You can use PHP3 to learn just now and all this knowledge as well as your code will be valid and valueable on PHP4.

If you'll be using the CGI version of PHP3, please be sure that you

• set up a chroot() running environment for your CGI (phttpd does this by default, Apache does this with a modified suexec - ask me if you need it).
• compile a version of PHP with --enable-force-cgi-redirect or you'll be opening a great security hole.

If you have any further questions, please subscribe to the php3@lists.php.net mailing list or have a look at the PHP Knowledge base. These are great ressources.

We are currently using Solaris as a server platform, with Apache or phttpd as a webserver and we are using Oracle and MySQL as databases. We are running PHP as scriping engine as CGI version and as Apache module in some instances.

You seem to come from a mostly Microsoft background, which is not where PHP is at home. PHP3 does not run as an IIS module, as far as I know, but only as a CGI version. This will make it perform much worse that for example CF or ASP on IIS, due to the abysmal performance of the NT platform and IIS as a CGI host - NT just doesn't fork. PHP4 will be running as an IIS module, but is in beta now and I would not build any production code on it - yet. As soon as PHP4 proves to be stable under load, it should outperform PHP3 by a factor of 5-10, though, plus the speed gain coming from being able to use it as a module on IIS.

On a Unix system (Linux, Solaris, doesn't matter) with Apache, PHP3 performs excellently as a module and can take any reasonable amount of load, provided you have enough RAM. We already know this from the Mindcraft benchmark - Apache must not swap and you must tune your MaxClients to match your RAM size to avoid performance degradation under high load. Many sites are parsing all pages, including their regular HTML, through PHP3 for convenience and the performance overhead is neglegible - if Apache can take it, Apache and mod_php can usually take it as well.

PHP excels in portability, support and in connectivity when benchmarked against CF. PHP will run on any old server platform and will talk to almost anything, and natively, where CF will most probably talk through an ODBC adapter. PHP includes some 10+ native database interfaces, including all major database vendors, and does LDAP, SNMP, SMTP, NNTP, IMAP4, POP3, some OODB and fulltext database protocols, can generate pictures on the fly, can generate PDF on the fly and so on. Writing extensions for PHP is trivial, if you can do reasonable PHP programming.

One point must not be left out of the equation when talking about PHP, and that is the online support. There are many large PHP mailing lists, including THE PHP3 mailing list, which are extremely friendly and efficient and usually generate correct and useful answers within 15 minutes. Also, the annotated online manual is a unique ressource for help, because it is learning and growing, incorporating user annotations. I have nowhere experienced anything that comes close to this kind in support, commerical or not.

My recommendation: PHP on IIS on Windows works, but will most likely not perform as exspected. It is nice for testing, but I won't go productive in this configuration. PHP on Apache on Windows works better, but will still not use PHP to it's fullest advantage. Also, you will make installation and maintentance unnecessarily difficult for you. PHP on Apache on any Unix will perform extremely satisfactorily, generate only minimal TCO, and is supported excellently. If you have at least minimal Unix knowhow inhouse, I suggest that you go for the full plunge in a test installation instead of an incremental migratory approach, because this way you will maximize the advantages of PHP and your server platform.

Re the migration from version 3 to version 4: PHP4 and PHP3 are drop-in compatible. There is no need to "port" from 3 to 4, because both languages are virtually identical. The differences are extremely minimal and well documented, also the development team is working on closing these final gaps between versions. Changes between version 3 and 4 are completly internal, switching from a fully interpreted system to a byte-code compiler/interpreter hybrid for speed reasons. Also, some language features have been added in an upward compatible and transparent way. We have tested the beta and found it to be living up to its promises in speed _and_ compatibility. Waiting for PHP4 won't pay: You can use PHP3 to learn just now and all this knowledge as well as your code will be valid and valueable on PHP4.

If you'll be using the CGI version of PHP3, please be sure that you

• set up a chroot() running environment for your CGI (phttpd does this by default, Apache does this with a modified suexec - ask me if you need it).
• compile a version of PHP with --enable-force-cgi-redirect or you'll be opening a great security hole.

If you have any further questions, please subscribe to the php3@lists.php.net mailing list or have a look at the PHP Knowledge base. These are great ressources.

We are currently using Solaris as a server platform, with Apache or phttpd as a webserver and we are using Oracle and MySQL as databases. We are running PHP as scriping engine as CGI version and as Apache module in some instances.

You seem to come from a mostly Microsoft background, which is not where PHP is at home. PHP3 does not run as an IIS module, as far as I know, but only as a CGI version. This will make it perform much worse that for example CF or ASP on IIS, due to the abysmal performance of the NT platform and IIS as a CGI host - NT just doesn't fork. PHP4 will be running as an IIS module, but is in beta now and I would not build any production code on it - yet. As soon as PHP4 proves to be stable under load, it should outperform PHP3 by a factor of 5-10, though, plus the speed gain coming from being able to use it as a module on IIS.

On a Unix system (Linux, Solaris, doesn't matter) with Apache, PHP3 performs excellently as a module and can take any reasonable amount of load, provided you have enough RAM. We already know this from the Mindcraft benchmark - Apache must not swap and you must tune your MaxClients to match your RAM size to avoid performance degradation under high load. Many sites are parsing all pages, including their regular HTML, through PHP3 for convenience and the performance overhead is neglegible - if Apache can take it, Apache and mod_php can usually take it as well.

PHP excels in portability, support and in connectivity when benchmarked against CF. PHP will run on any old server platform and will talk to almost anything, and natively, where CF will most probably talk through an ODBC adapter. PHP includes some 10+ native database interfaces, including all major database vendors, and does LDAP, SNMP, SMTP, NNTP, IMAP4, POP3, some OODB and fulltext database protocols, can generate pictures on the fly, can generate PDF on the fly and so on. Writing extensions for PHP is trivial, if you can do reasonable PHP programming.

One point must not be left out of the equation when talking about PHP, and that is the online support. There are many large PHP mailing lists, including THE PHP3 mailing list, which are extremely friendly and efficient and usually generate correct and useful answers within 15 minutes. Also, the annotated online manual is a unique ressource for help, because it is learning and growing, incorporating user annotations. I have nowhere experienced anything that comes close to this kind in support, commerical or not.

My recommendation: PHP on IIS on Windows works, but will most likely not perform as exspected. It is nice for testing, but I won't go productive in this configuration. PHP on Apache on Windows works better, but will still not use PHP to it's fullest advantage. Also, you will make installation and maintentance unnecessarily difficult for you. PHP on Apache on any Unix will perform extremely satisfactorily, generate only minimal TCO, and is supported excellently. If you have at least minimal Unix knowhow inhouse, I suggest that you go for the full plunge in a test installation instead of an incremental migratory approach, because this way you will maximize the advantages of PHP and your server platform.

Re the migration from version 3 to version 4: PHP4 and PHP3 are drop-in compatible. There is no need to "port" from 3 to 4, because both languages are virtually identical. The differences are extremely minimal and well documented, also the development team is working on closing these final gaps between versions. Changes between version 3 and 4 are completly internal, switching from a fully interpreted system to a byte-code compiler/interpreter hybrid for speed reasons. Also, some language features have been added in an upward compatible and transparent way. We have tested the beta and found it to be living up to its promises in speed _and_ compatibility. Waiting for PHP4 won't pay: You can use PHP3 to learn just now and all this knowledge as well as your code will be valid and valueable on PHP4.

If you'll be using the CGI version of PHP3, please be sure that you

• set up a chroot() running environment for your CGI (phttpd does this by default, Apache does this with a modified suexec - ask me if you need it).
• compile a version of PHP with --enable-force-cgi-redirect or you'll be opening a great security hole.

If you have any further questions, please subscribe to the php3@lists.php.net mailing list or have a look at the PHP Knowledge base. These are great ressources.

Quicksort (script ran 50 times)

ccc version: 27s
gcc version: 30s

Mandelbrot (script ran 50 times)

ccc version: 35s
gcc version: 39s

ala cold fusion style embedded script in your html: use PHP. Free. Open source. Woo hoo. PHP4 is really good. Fast. OOP. php.net. (but don't use PHP3 if you can get 4beta2).


Last I checked, IDEs don't work over a low bandwidth remote shell. I think I will stick with vi, thanks.

Very good observation. In December of 1992, I wrote a couple of small documents dealing with setting-up X-Windows under SLS (rocket science compared to how easy it is now). You're right about the "don't feel qualified" part. I never asked them to be made into a HOWTO (later when HOWTO's first became popular) or part of a HOWTO, because of that. I've coauthored two books with Prentice Hall, and I confident in the job I did. With a HOWTO, I was afraid I would get 10,000 e-mail messages complaining about my mistakes. With my book, I only got a few dozen letters concerning my several (large) screw-ups. In 1989, I started a Usenet FAQ for Great Dane owners in rec.pets. My employeer at the time got complaints about the job I did. I don't want risk my job to contribute to documentation. Maybe, a centralized anonymous contact system would be nice. I could get feedback on my work and improve my work, without it jepordizing my position.

I would suggest something between the annotated PHP manual and slashdot be created to hold these more casual "implementation notes." The advantage over Deja, is that they could categorized, modified, or deleted if redundant.

"Connection reset by peer" is a rather strange message. Check your error log. If it says something about receiving signal 11 (sigsegv) you should follow these instructions and post a PHP bug report.

Also make sure to always use the latest available release. 3.0.12 is already very stable, future releases of the php3 tree will only feature bug fixes.
--
OS lover

$slen = strlen($textstr);
for ( $i=0 ; $i<$slen ; $i++ ) {

if(substr($textstr,$i,1) == " ") {
printf("<img src=/images/sb-.png>");

} else {

printf("<img src=/images/sb-%s.png>",substr($textstr,$i,1));

}