Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
News

PHP3/4 as Web Development Platform? 204

Erestar asks: "I work for a small network integration company that also handles a good bit of web application design and hosting. Right now we're running 2 clustered NT servers along with Cold Fusion. Since my introduction to PHP3 I have been strongly pushing to run it in conjunction with IIS while still keeping the Cold Fusion server active. What I need are any comments or suggestions as to the validity of my cause. Will PHP3, running as a module for IIS, seamlessly fail over? Has anyone encountered any problems when running PHP3 and Cold Fusion Server at the same time? How limited is PHP3 as far as script size is concerned? Another issue that has arisen is the practicality of doing this. Are there any benefits to running PHP3 that Cold Fusion cannot provide (aside from "its just so damn cool")? Would I be better off committing myself to writing custom CF tags and COM objects with VB or C++? Would I be better off waiting to for a new release of PHP4?" Erestar goes on to describe his applications. Click below for more.

"We work with practically anyone; our clients range from Used Car dealerships to billion dollar banking firms. Nearly all of the sites are database driven, most with ODBC to Access databases (we're planning on turning MS SQL Server on any day now, though). We're also developing a tracking application that will manage most of our business requests and anything else we can toss in. It is this application that I would like to code with PHP3. Any information that you could supply would be greatly appreciated. "

This discussion has been archived. No new comments can be posted.

PHP3/4 as Web Development Platform?

Comments Filter:
  • by Anonymous Coward
    You should check out zope

    http://www.zope.org

    It is pretty slick. Implemented in python.

    I did some stuff with PHP, but I ended up
    implementing the system with ModPerl/EmbPerl.

    -- cary
  • by Anonymous Coward
    I have to say, PHP is *most* suited for work on a Unix box. It was origionally developed for and still is best on a Unix box. Having said that, it's still very powerful and functional on NT under IIS. Why do you want to change from CF to PHP? I honestly wouldn't if you are a solely NT farm, CF does have more functionality than PHP when running on NT. Just try to balance the pros and cons and pick the best thing for your situation. Keep in mind that while not hard, you will have a learning curve with PHP, if you already know ASp and/or CF, you're already one step ahead.
  • by Anonymous Coward
    Speaking of ASP and PHP.. I'm the author of asp2php (http://home.i1.net/~naken/asp2php/).. and hopefully sometime in the next week or so I'm going to release a cleaned up version with PHP4 session support and make it a free program (not nessessarily GPL). So if anyone wants to help me out with it let me know...
  • I believe PHP with IIS actually spawns a new process for every request, instead of spawning a new thread like it does with Linux. As anyone who knows the difference, this causes a MAJOR PERFORMANCE problem with PHP on NT.

    If you are going to use PHP3 or PHP4, use it on the proper platform. Talking PHP up based on how well it runs on Unix systems, and then deploying it on NT and expecting the same may leave you with pie on your face.

    Of course, someone will correct me if I'm wrong on this matter.
  • by Anonymous Coward
    "but it has major security holes"

    What major security holes?

    The issues with the example applications?
    You should never install example applications on a production machine. ASP/IIS has very similar dangerous example applications and samples!

    The template encryter being cracked?
    Microsoft's ASP encrypter is cracked too.

    MDAC RDS?
    Has nothing to do with CF, it's an MDAC/IIS flaw.

    %20 bug?
    That's a Netscape/WebSite bug, not CF.

    ::$DATA bug?
    That's an IIS bug.

    Access 'pipe' command bug?
    Access, not CF.

    I'm not aware of any other security holes that affect Cold Fusion.

    Please enlighten us, and back up your FUD.

  • by Anonymous Coward
    That's funny. I'm running a very complex transactional website on ASP/SQL-Server. We had various problems along the way when we didn't know what we were doing, but we were able to figure them out and now the site runs smooth as silk.

    I'm rooting for open-source as much as anyone, but MS-haters tend to throw up their hands and say it doesn't work as soon as they run into a problem with MS software. It does work, you just have to figure out how to do it right. It doesn't help that a lot of recommendations for beginners are contrary to real best practices.

  • by Anonymous Coward
    Signal, please learn to read and COMPREHEND. PHP4 is most definitely "Open Source". The Zend Library is under the QPL, just like the QT libraries, which means if you develop a commercial application which links to or uses the Zend library, you must purchase a Zend commercial license. Just like a commercial application which links to and uses the QT libraries. Go back and read the licenses again, and this time payt attention to the differences between PHP and Zend.
  • I'd have to agree with you on reading the book, it's got some interesting stuff in it (haven't finished all of it yet though). Especially concerning site design, planning and different ways to design the site.

    Nice pictures with it too...

    Wayne
  • by drwiii ( 434 )
    I used PHP for the design of my OS discussion website [osonline.org] and have had nothing but good experiences with it. I can't comment on it's stability as a Microsoft IIS module, since I haven't used IIS.
  • fhttpd [fhttpd.org] FTP/HTTP server that I wrote has its own interface with php. It allows things like configuring sets of php scripts to run under different userids, make pools of processes that use some limited resources like database connections and some others. php3 is supported as a module, and I am porting the interface to php4, so at the time of php4 release it will be supported as a module, too.
  • There are no known security issues, correct. Sure, it is possible to install PHP in an insecure manner, but it is possible to install just about anything in an insecure manner.

    -Rasmus
  • To avoid the lowest common denominator problem with db abstraction layers. It is really not that difficult to put your db layer code in an include file like db.inc and if you do change your database, just change your db_* functions. And for the performance-oriented people out there having *all* API features of a specific database available is a huge bonus. There are databases out there that are so different from each other that trying to abstract them into a single API just doesn't work very well.

    This comes up a lot, but how often do you really change your backend database? And if you are changing from MySQL to Oracle, you are going to have a lot of more complex issues to worry about. Or try moving from MS-SQL to Oracle with triggers and stored procedures and stuff to port. Trust me, changing 10 lines of PHP code was a breeze compared to the headaches of moving the schemas.

    Having said that, we are looking into a DB abstraction layer for PHP 4, but I really do believe from experience that this is not such a big deal.

    You also have the option of sticking with ODBC calls. Most databases support ODBC and some even have native CLIs and PHP is smart enough to let you use the ODBC interface to access these so you are getting native API performance through ODBC calls. This is known as unified-odbc in PHP-speak.

    -Rasmus
  • Well, the versioning is still work in progress. It should actually just be called DA right now. Stay tuned for the V part.. ;)

    And I do agree that Zope is a very nice environment. The scope of Zope (ack!) is larger than PHP's. It could have been built on top of PHP actually, or mod_perl or even Java. I don't think comparing the two directly is really correct. A bit of an apples and oranges comparison. Then again, LinuxWorld put PHP up against Qt recently and Qt won. So comparing Zope and PHP is more like comparing an Apple to an Apple core.

    And yes, there are ways to do most of the things you listed for Zope with PHP. Like the WebDAV support. Install mod_dav on your Apache server and there you go. Sessions and persistent objects are there in PHP 4. To get all of Zope's functionality with PHP would take a bit of work and piecing things together. Various people are working on PHP-based environments like that. We tend to just worry about providing the lower-level functionality.

    -Rasmus
  • by Rasmus ( 740 ) on Wednesday September 22, 1999 @06:47AM (#1667084) Homepage
    Well, you are wrong. Rasmus on Slashdot does actually == Rasmus from PHP devel.

    The note you quoted from Bruce was written in July. He says right there that we agreed to fix those issues back in July. Being September now, that has obviously been done. And they were just slight wording changes.

    As for your CGI thing. You are being silly. You quoted a CERT advisory from 1996. Being September 1999, that has obviously been addressed as well.

    -Rasmus
  • by Rasmus ( 740 ) on Wednesday September 22, 1999 @04:17AM (#1667085) Homepage
    You are misinformed here. PHP 4 is very much Open Source and it has been run by Bruce Perens. The Zend component is under the QPL which has been deemed to be Open Source compliant and the rest of PHP is under an Apache/BSD style license.

    And your cgi concerns aren't too well-founded. The thing you can do with the cgi version, at least under Unix, is to run it as your own user id through suExec which is quite safe. Under NT, who knows, but then I don't think IIS has .htaccess files anyway.

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

    And finally, PHP 4 has an ISAPI version coming so from a performance perspective it should be quite competitive, and most likely quicker than CF on NT.

    -Rasmus
  • Ah, I forgot to mention: WDDX [php.net] 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 [php.net] that comes with your Apache or is available separately, enabling you do decode and perform XML RPC.
  • Sascha has already addressed most of your issues with PHP3. I might add that session management is builtin in PHP4 and is available as an addon in PHP3. See PHPLIB [netuse.de] for more information. PHPLIB also provides a quite powerful and easy to use database abstraction.



    Here is how you do a foreach-loop in PHP:

    reset($ary);
    while(list($k, $v) = each($ary)) {
    print "key = $k val=$v\n";
    }


    Here is how you speak to any database, using
    the PHPLIB database abstraction:


    $db = new DB_Example;
    $db->query("select * from mytable");
    while($db->next_record()) {
    print $db->f("fieldname");
    }


    The DB_Example class is a subclass of DB_Sql provided by PHPLIB and knows the connection parameters (host, username, password, database) as well as the specific details of your DB server (such as vendor, protocol and the like).

    Here is how you handle sessions using PHPLIB:


    page_open(array("sess" => "Example_Session"));

    $somevar = "somevalue";
    $sess->register("somevar");

    page_close();


    $somevar will now be present on all session pages that use Example_Session. We propagate sessions using cookies, automatically and transparently falling back to other means if the user does not support sessions. In PHP4, session support is buildin and available without PHPLIB. You will be able to use PHPLIB with PHP4, too, taking advantage of the builtin support.

  • by kris ( 824 ) <kris-slashdot@koehntopp.de> on Wednesday September 22, 1999 @04:13AM (#1667088) Homepage
    I have never used CF in a project, but have evaluated it before committing ourselves to PHP.

    We are currently using Solaris [sun.com] as a server platform, with Apache [apache.org] or phttpd [signum.se] as a webserver and we are using Oracle [oracle.com] and MySQL [mysql.com] as databases. We are running PHP [php.net] 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 [mailto] PHP3 mailing list, which are extremely friendly and efficient and usually generate correct and useful answers within 15 minutes. Also, the annotated online manual [php.net] 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 [mailto] mailing list or have a look at the PHP Knowledge base [e-gineer.com]. These are great ressources.

  • by jabbo ( 860 ) <jabbo@@@yahoo...com> on Wednesday September 22, 1999 @06:41AM (#1667089)
    Perl is a lot faster to develop in than Java. Really. I've done complicated stuff in both. When you really push the envelope, Java's standard API abstraction barriers don't go far enough.

    JSPs are okay, but so is embedded Perl or VBasic.

    Cocoon is very unwieldy right now, and probably not yet worth the effort unless you are a huge shop with lots of Java and XML devotees. The examples assume an Oracle backend. That should tell you something. (Yes, I've played with Cocoon as well. Cocoon 2 may inded be revolutionary...)

    I have never heard of Midgard and I've been around for a while now. This indicates to me that it could be difficult to hire someone quickly and get them up to speed on it. OTOH, if it's just like PHP only better, I could be quite wrong.

    Just my experiences and thoughts.

    Personally, I don't mind servlets, mod_perl, OR mod_php. They're popular for different things, so for maximum code reuse (laziness) I choose whichever gets the job done fastest.

    (Zope, incidentally, is quite cool and OO, and would be great for a new installation, but too much of a transition IMHO for a preexisting site)

  • And it runs either as a seperate process or inline with the current httpd process on Linux depending on how you configure it.

  • MySQL is only good for simple database appilcations. It is too simple to handle complex business applications including a competent order entry system(I work on a order entry system used by Fortune 500 companies...). For these applications, Oracle, Informix, SQl Server(ick!), or DB2 are a must.

    As for Cold Fusion, it is not a a scripting language, but rather, an application server. In it's most advanced iterations, it supports clustering, application partitioning, and the like. Again, if you are writing a complex, high volume business application, these are mininium features.

    Try writing a order entry system for a large scale manufacturer that must implement commodity based pricing models, promotion management, real-time inventory management, and freight management -- you will discover that PHP3/mySQL will fail miserably. In fact, I would be willing to bet that we couldn't implement our software in such an environment.

    So, to sum it up, your suggestion is great for little web apps. But, if your market is going to include apaps for the big boys(like this fellow obviously needs), he should strongly consider tools such an application server such as Zope, WebLogic, or SilverStream. Also, go with a Solaris or Digital box running Oracle or an RS/6000 running AIX and DB2 -- SQL Server is a contentious hunk of crap. Finally, you should trash IIS,and get Apache up on the same platform as you choose for the RDBMS.

    As an aside, I don't mean to dis Linux as the platform of choice, but Linux is not ready to do DB serving for the enterprise. SMP isn't quite there yet, and the products are just too young. For example, Oracle running on Solaris is 10+ years old and solid as a rock. For this type of application, robustness and stability are the most important considerations. In the busines world, no cares if the hardware/software combo costs $500,000 if it is available 24/7/365. But, if it is $10,000 and crashs frequently, business is lost and therefore, money is lost.
  • With all due respect to Rob, SlashDot is a relatively simple application from a transactionaly perspective. It just happens to be incredibly useful. When you consider Slashdot, it does blind inserts and updates without any regard to success or failure.

    The question must be viewed with the needs of through the lense of ASP/ISP's aiming to provide web hosting services. In order to make money, ASP/ISP's must be able to host eCommerce applications. Therefore, he should direct his efforts toward putting the infrastructure in place for such a transition. Mind you, such a transition is major management and technology shift wich will probably take anywhere from 12 to 18 months to draft a strategy(i.e. select hardware and software platforms), acquire the assests, and train/hire the needed human resources.

    To my mind, mySQL would be a poor choice in this scenario. As far as PHP goes, it could be uses in conjunction with Java, Perl, C, etc. in the front end, but it is NOT an application server. A WebLogic, Zope, WebSphere, Gemstone, etc. should sit between the web server and te database.
  • PHP is fine for taping a read-only UI to a database, or doing little cleanups and 'we need this tomorrow' stuff. Its fast and familiar, being similar to perl.

    However, I think that Java Servlets are really the way to go in large systems where code reusal and proper design methods are critical. You can really stick with MVC (Model View Controller), writing generalized stuff to model your data access, controller pieces (which are the servlets) to describe the flow of your application (select product, click ok on license, enter cc info), and then put all your layout specific stuff in the JSPs.

    You'll reuse your core stuff all over the place (same as if you modulize your php stuff), and if you separate your content from your control, you can use the same servlet code calling different JSPs to provide your applications in different layouts and languages

    And yeah, you can technically *do* all that with PHP3, there's nothing stopping you from separating it all out that way, but if you use Java/ Servlets/ JSPs the architecture really encourages you to do it properly. I haven't done any specific speed tests, but the servlets stuff is currently supporting quite a bit of activity (1000 folks a day) on an NT box of medium range (dual p350s). We haven't migrated to Java 1.2 yet, so hotspot isn't an option yet, but its another bonus. Soon as we convince the higher-ups, its off to UNIX... :) Zipwow

  • While it is certainly true that there are things that PHP and MySQL can't do, I am sure that it is more than a replacement for this person's current setup.

    After all, he is currently using Cold Fusion and Access.

    As my boss says frequently. "You only need an Aircraft carrier if you are landing planes on the water. If all you are is going fishing, a rowboat is fine."

    I am sure that Cold Fusion and Oracle are quite amazing, but look at what CmdrTaco has done with Perl and MySQL. How many sites really need more than that? And as for the database, if you need a database with more features, most people would be just fine with PostgreSQL. The guys at postgresql.org have done some pretty amazing work.
  • by citmanual ( 2002 ) on Wednesday September 22, 1999 @04:06AM (#1667095)
    I have personally not used Cold Fusion or Zope. But, I require *nix based solutions doing basically the same stuff you have done.

    I think PHP is great. Its fast, it works well and is very well featured. I think that it works best statically built into apache, and I have only used it with Linux and FreeBSD. I think you are best off to wait on PHP4. Just start with 3, and then migrate as needed. I don't forsee too much incompatibility between the two, and as someone who gets way to many "Its broke" phone calls, I can't imagine delivering a beta backend for an important app.

    As for Zope, it looked to me to be a simpler language than PHP, although powerful. I think it is good for dynamic web pages, but big web apps (such as the sort I create) are out of its scope.

    I think that sticking with NT and CF is a poor choice. My firm almost always either hosts the web app for the client (we have one client that is a conglomerate of 300 companies nationwide) or delivering an inexpensive unix (linux, freebsd) dedicated server. I think that web apps are so easy to decompile, or just yank the source, that clients think they can edit it, and you have to fix it. I prefer to lock them out unless I truly feel they know how to code at all. I think NT is a terrible OS and that you need to get away from that, fast.

    But, I suppose I am a bit of a zealot. grin....
  • Please don't take my comments regarding Zope as a deprecation of PHP. I just happen to be a satisfied Zope user, there could be PHP features just as nice that I'm not aware of.

    And I understand there is not an existing license problem with PHP's open-sourceness. If that's not the case please explain.

    Thanks

    Bruce

  • A WebDAV client could allow you to drag a document from the desktop onto your web server, to drag documents around on your web server, and to open a document on your web server directly into your editor.

    You should, in fact, be able to write a remote filesystem client for the WebDAV protocol, and you could put it in the Linux kernel and make it work like the NFS or Samba client. That would WebDAV-enable a lot of Linux tools right away. Someone go do that and tell us when you're done :-) .

    And the V in DAV is for versioning, but I don't have a clue about how the versioning works.

    Thanks

    Bruce

  • by Bruce Perens ( 3872 ) <bruce@perens.com> on Wednesday September 22, 1999 @04:22AM (#1667098) Homepage Journal
    I'd like to chime in regarding Zope. The scope of the problems it solves is simply awesome, and it's got an Open Source license approved by yours truly. The feature-list is quite impressive:

    • PHP-like language (called DTML), with new experimental XML-compliant form of DTML as well which can be handled by XML editors.
    • Managed via your web browser, there is no need to have a shell account to maintain a web site, and no need to be in the /etc/passwd file.
    • Access control including user-defined roles.
    • User information, roles, and permissions can be local to a sub-tree of a larger site, and can override what is defined higher in the tree.
    • Object persistence.
    • Content management with session control. You can join a session to test new content without having that content appear to anyone who has not joined that session. Commit or discard the session when you are done.
    • WebDAV (drag-and-drop management of web sites) works today. Too bad the only WebDAV client you can get is IE5, but that'll change - it's an open standard.
    • FTP access to your web site and its dynamic methods.
    • Database integration with built-in query system and sophisticated search interface.
    • No need for CGI. Export methods of classes via the web. Persistent program rather than CGI which restarts an executable with every call.
    • Transaction processing transparent to the programmer. If an uncaught error is posted during a transaction, the entire transaction is backed out of the database cleanly. Data is never left in an inconsistent state. There is also a programatic interface to transactions, but you don't generally have to use it.
    • It's pretty fast and low-overhead, too. My Pentium III 450 running Linux and Zope has survived being slashdotted many times. Sure, my Pentium 120 does that using just Apache, for static files. My Zope site, on the other hand, is very dynamic.
    • Web-based definition of classes, or you can use python.
    • Call from Apache, or run it as its own web server. If your site is entirely Zope, you can turn off Apache and save the overhead.
    • Multi-threaded.
    • Written in Python, with a tiny bit of C.
    It takes a few days to learn everything that's in there, there's so much. I suggest you go over to zope.org and get started.

    Thanks

    Bruce

  • Hello,

    I used php since version 2.0 and liked it very much. It's extremely simple to write in and for the most part gets the job done.

    Session management wasn't really addressed with PHP3. There are some libraries/classes out there that do it and I've used phplib internally in our organization and it has worked quite well.

    I've recently switched completely away from php3 in favor of mod_perl. I write most non-web based applications in perl and found myself banging my head on the regular expressions and lack of libraries with php3. Why reinvent the wheel?

    mod_perl can seem overwhelming at first. I've written a web-based mail application using Mail::Cclient and a bunch of other modules in the course of about 2-3 days of off and on programming. mod_perl doesn't come with session management built in but Apache::Session takes care of it.

    I've settled finally on HTML::Mason. This is a very powerful way to write web-based applications and I highly recommend you check it out. Their home page is at http://www.masonhq.com/ [masonhq.com]. The way the code is embedded in HTML is very similar to the way PHP3 does it with some powerful other features (dhandlers, ahandlers, etc.).

    My biggest gripe about PHP3 is the lack of classes. There are a dozen sendmail.php3 classes and some other good stuff on the PHP3 code archives but with mod_perl, you capitalize on the entire CPAN with literally thousands of well-written and well-tested modules.

    Anyway, that's my two cents. My experience with these have been with Linux only so YMMV with a non-UNIX platform.

    Synaptic

  • I've been using PHP for two years now and just love it. I've written web applications ranging from an intranet based datamart to a Kiosk swipe station with great success. I highly recommend PHP to anyone who wants to develop web applications.



  • "I've used PHP on Linux with Apache and have had lots of luck with it, but that's because it's designed to work on UNIX-y boxes with Apache, for the most part. Trying to wedge it into an NT/IIS situation is, IMHO, Not A Good Idea."

    I agree. You sell them on it and push it as open standard to get away from proprietary solutions, you run it on a crappy OS and a crappy HTTP server instead of the platform it's built for, and the higher-ups blame the app when it bombs out, instead of the platform. "Open Source? Apache? We tried that PHP stuff on the IIS box and it cratered in a week."

    Wait for a chance to implement it on Apache/GNU/BSD or it'll sneak up and bite you in the ass.

  • I have PHP3 running on a couple of sites that I have set up. (Sorry you can't get to them) I've found PHP3 does very well and handles all the tasks that I've thrown at it. I haven't had any performance issues yet but then my sites aren't high traffic as compared to what yours might be.

    Aspects of PHP3 that I like are:

    • simple to learn, use, modify and deploy
    • plugs into pretty much any database
    • lots and lots of function there so you can do just about anything.
    • It's open source with a strong vibrant following.

    Besides you really should get off NT....

  • Personally, I've been developing Cold Fusion applications for about 2 1/2 years now, and I think Cold Fusion is one of the greatest products the Win32 server arena has ever seen. Crashes from IIS are not too uncommon, but I don't ever recall Cold Fusion crashing or even hiccupping in the least. If you are having problems with Cold Fusion stability on your server, you should probably take a closer look at the installation.

    Also, if you are looking to implement some kind of fail-safe, I would highly recommend Zope over PHP3. I've used Zope as well, and I think it far outperforms PHP3 in just about every aspect I can imagine. You can check out Zope at its website [zope.org].

    Also, as someone else said, keep on Allaire's heels-- they are supposed to have Cold Fusion for Linux out by the end of the year.

    Good Luck..
  • Rasmus on slashdot != Rasmus from php devel. If he was.. he would have come out and said it. Anyway, here's a snippet I pulled from license-discuss. Now, I'm not the one to certify a license as being OSD-compliant or not... but I do know there are some issues with the license.. and I also believe it isn't open-source (see previous post).

    From: bruce@perens.com
    07/24/99 12:04
    Subject: Re: gpl backlash?
    To: license-discuss@opensource.org, signal11@mediaone.net

    There are always anti-GPL messages on slashdot, many from people who don't write software. I'd not concern yourself with them. There are also lots of
    people who speak in favor of the GPL and more vendors are using it lately.

    The PHP4 license was not quite identical with the QPL 2.0. We discussed some license problems with the PHP folks and they will fix them.

    Thanks

    Bruce


    --
  • ... So then would I be correct in assuming that there are no outstanding issues with using the CGI version of php* ?

    --
  • Actually, the GPL does allow commercial development. You can even keep the changes to yourself. But if you give your changes to anybody else.. you can't stop them from.. say, uploading it to freshmeat, or selling it, or really anything. That's my read of it, anyway.

    --
  • *cough* We were discussing what the GPL allows.. not the QPL. Take your own advice and look before you leap (or post). Yeesh...

    --
  • Alright. Well, thanks for clarifying the matter. Boy do I feel stupid now.... :)

    --
  • And your cgi concerns aren't too well-founded. The thing you can do with the cgi version, at least under Unix, is to run it as your own user id through suExec which is quite safe.

    I think they are. Check out this [cert.org] CERT advisory, as well as this [php.net] 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 [php.net] 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 [opensource.org] link for the full monty.

    --

  • by Signal 11 ( 7608 ) on Wednesday September 22, 1999 @03:44AM (#1667110)
    I'm sure that other people will give you the scoop on all the advantages of php3/4/zend and the usual recommendations, so this post is dedicated to informing you of the disadvantages and shortfalls of your implimentation. Likely this post will be -1'd, but I feel it important to mention.

    I would seriously recommend using the mod_php3 modules under Apache due to performance and security. If you run PHP as a CGI script, you can do nasty-evil things like read the .htaccess files under apache. There is also no "safe mode" for the CGI module (I haven't verified this, however).. which means one coding slip-up and you hand the remote user all the priveledges the webserver has on the system (which given that you'd be running NT, is probably full access). Even with safe mode, you will still have some additional security concerns that the apache module doesn't have. :(

    The other problem with PHP4 is the licensing - it is not open source. Bruce Perens and the OSI have been working on it for awhile now (a long while ago *muttering*) but it isn't fixed yet. Go over the license and see if you can live with it.. otherwise stick with PHP3 (which meets the OSD).

    The single compelling reason to use PHP over third-party or Microsoft offerings is the database support. You should know that PHP4 brings ODBC driver support (via iodbc under linux, YMMV under NT) so that you can access alot more RDBMS systems than before. This is a definate consideration when looking at the client's needs. I will again reiterate that NT isn't the best platform for serving dynamic content from.. and would urge you to consider using a unix-based solution.. it's more scaleable, easier to maintain, and more reliable than it's NT counter-parts.

    --

  • I felt that I should post as I have seen alot about PHP, and Perl (and some other Unix) solutions. Plus, I've seen a lot of knocks on ColdFusion because it's not open source - just because it's not open source doesn't mean it's bad... And, just because it's open source doesn't mean you'll have the expertise to fix it if something is wrong with it.

    Those disclaimers aside - I have used PHP3, Perl, ASP, and CF extensively, if not exhaustively. The metaphore of embedding code into a page is the superior one for most applications - with the exception of when you need to do an involved server side process. All of these technologies support both means of processing - by hook or crook.

    Cold Fusion does have several niceties that are not easily found (i.e. built into) the other solutions. First and formost the CF FORM tag. One of the nicest things about Cold Fusion is it's ability to generate client side Javascript automagically (you do have to give it some direction). The CF FORM tag allows for near automatic generation of JavaScript that will perform client side verification of field contents.

    Unless I'm missing the obvious neither ASP, or PHP, or Perl allow for this easily. Yes there are tools and IDEs that leverage those technologies to enable this - but with Cold Fusion - if you know the markup tags, you can still use a plain old text editor to create pages - which when processed automatically send the appropriate HTML to the client depending on the type of client - and Javascript that handles a lot of stuff.

    Having said all that - I don't particularly view CF as a "programming language" - it's a markup system. It does have several programming like features - and is extensible in that you can create add-ons and tags that leverage them - but it's not a programming language in the Perl, PHP, ASP (VBScript/JScript) tradition.

    In short, if you need to do substantive additional processing to data retrieved from a database, you're better off with Perl, PHP, or ASP. On the other hand, ColdFusion comes with some very nice Java based applets that it can leverage on the client side.

    In short, they are all pretty good technologies, each has strengths and weaknesses. I wouldn't switch based on any "cool factor" if you have significant investment in Cold Fusion, and IIS. If you need to expand those capabilities, I would suggest you use ASP - as it's built into IIS. No matter what a lot of people say, it's fairly stable - a lot of sites use it successfully, and seem to have just as few problems as /. - which uses Perl on Linux.

    - Porter
  • by hatless ( 8275 ) on Wednesday September 22, 1999 @04:49AM (#1667112)
    PHP's nifty, but the trend is away from loading business logic and presentation logic onto the same layer, as PHP and Cold Fusion both generally do. Cold Fusion has been moving toward a 3-tier approach with the addition of a separate app server, but it's not really there yet in terms of being able to run on separate hardware and having intelligent failover at the middle tier.

    This is where in the NT world the typical scenario of hosting COM objects on something like MTS comes in, and ASP or Cold Fusion in front of it.I've heard it doesn't work thrillingly well in some cases, especially when you're trying to host Java COM objects, but the approach is right and there are ways to make this work well.

    The usual platform-independent approach is to use a CORBA (for C++ or Java) or EJB (Java) app server, or at least plain old Java Servlets, which does essentially the same thing, typically with JSP for the presentation scripting layer. One nice thing about JSP is that they compile to Java bytecode and run very fast indeed.

    Yes, you can run ASPs on a number of Unixes, Cold Fusion on Solaris (and gosh, don't they have a Java implementation of their server piece now?). And a number of Unix-family OSes can also host and/or access COM objects, though they won't magically have access to Win32 APIs.

    And yes, the JSP/Servlet/EJB/CORBA approaches work very well indeed on NT as well as Unixes, with most of the higher-end app server vendors all abandoning their proprietary technologies and standardizing on this set of technologies these days.. See Broadvision, BEA Weblogic, ATG, Sun NetDynamics, Netscape Appserver, and IBM WebSphere for just some examples of the vendors doing this. It's mighty compelling.

    On the low-end, getting started with the JSP/servlet combo can be very inexpensive and very stable indeed on any OS. There are free servlet engines (which you can use to connect to CORBA and COM objects without much fuss) for all the popular webservers, free JSP environments that can sit on the servlet engines, and many choices for getting into EJB and CORBA, from free (albeit sometimes not ready for wide use) to commercial (industrial strength). The great part about this is that you end up with code at each layer that runs fast and is extremely portable to and between the most scalable and bulletproof app servers around.

    As for commercial RAD tools, you may want to look into a new version of Drumbeat that generates JSP instead of ASP. And most modern Java IDEs make for great EJB and servlet development environments.

    Can't speak for the forthcoming PHP4. It may come closer to this sort of thing.

    One thing to say in PHP3's favor is that some pretty large and high-volume sites do use it, though the heavy-traffic ones probably have the nastier logic on a middl tier or as stored procedures in the database.
  • Ok, this has nothing to do with this thread. If you don't care about /. moderation issues, stop reading now.

    Still with me? Good. So, my comment above (the one that this is in reply to), you'll note, was comment number 5 to this story. When comments started to appear, it was the first one, by virtue of a default +2 score. Someone gave it one moderation point for being informative or interesting or something.

    So later on, some other people had written better comments than mine, and got nice high 4's and 5's, and did anyone notice that now comments "float" up to the top of the page when they get high scores? So suddenly my post (which started out first), was way down the list, and got scored down as "redundant"! Ok, I don't know about you, but dammit, I said it first! All those other people are the redundant ones.

    Seriously, I'm not just bitching because I got mod'ed down. This is a bad feature of the system-- in fact, most of the recent changes are generally in the direction of making sure that the high-scoring stay high-scoring, and the low scoring disappear. Think about it-- you bubble high-scored posts up, they get more readers, and more moderators notice them and give them higher scores. Meanwhile, some AC said something brilliant down the page, but no one ever gets there.

    I don't know what to do about this... just something to chew on.

    ----
    We all take pink lemonade for granted.

  • But look at it from the point of view of a reader in a hurry. The fact that you said something first doesn't make any difference if there's a higher-ranked posting (for whatever reason) that also says it. This is true. And moving higher ranked comments up also discourages "first-post"ing (although it also produces some really odd "first posts," I've seen ones that are at the bottom of the page, and numbered like 76. What's up with that?). But I still feel like it encourages people not to read comments that might still be worthwhile. Isn't this what we have thresholds for, after all? Well, regardless, it's not my site, and Rob can still anything he damn well pleases. I feel like the /. community is a really cool and unique, and also fragile, thing, though. Some of these changes worry me a bit. Any idea what purpose karma will ultimately serve (y'know, besides determining what form you get reincarnated in)? CT keeps mentioning that he's "using it in other areas of the site," etc. I'm curious.

    ----
    We all take pink lemonade for granted.
  • I can't comment on cold fusion, as I haven't used it. Generally when I need to create a web application, it comes down to php3 or perl (apache/mod_perl). I've found that php3 is *really* good for fairly lightweight stuff, especially simple DB-driven applications. If you need to write a web interface for a database, and it doesn't need a lot of complicated user info or state info, php3 is a great choice. the database syntax is very easy, and it talks to most anything.

    Perl is also good for the same things, but there's a bit more overhead, and that needs to be balanced against what you need to do. For larger applications, I would definitely choose perl, since there's just a lot more you can do with perl.

    I've also used php3 for building template based web sites which have active and static parts. It's also really nice for this. Want your pages to all look roughly the same? Code a header and a footer up in php3, and just include them in a template. Makes site management really easy, and the syntax is fast to develop in, if you have any perl or c experience (or ASP or probably cold fusion, for that matter).

    I know people have built very complex applications in php3, and it seems to work for them. I've never done that though. As always, whatever makes you happy, go with it. :-)

    ----
    We all take pink lemonade for granted.

  • Point made. My post above relates specifically to Linux installs (Apache/mod_php). Use NT at your own risk (hey! that's what the EULA tells you anyway, right?) :-)

    ----
    We all take pink lemonade for granted.
  • My boss and I attended his lecture at MIT. It was well worth the time and money. I don't agree with all his ideas but he's one of the few pundits (is that a dirty word yet?) that sees the big picture.

    Also, anyone who put JiveWeb on the internet has to be pretty cool.

  • We implemented MobyGames [mobygames.com] in PHP3 at first, but it became very apparent that, with our multiple queries and data integrity checks, it wasn't going to cut the mustard. (PHP4 may solve these problems if it avoids having to compile/interpret code every single page load, but I haven't tried it, so you should.)

    We ended up rewriting the project in modperl and we quadrupled our speed.
  • If you're wedded to IIS, and want to talk to ODBC without messing with ASP and the rest of the Micro(do it Our way)soft server-side stuff, you might want to look at Internet Database Connector: it's been a native IIS/ISAPI facility since the beta before IISv1, and it's fairly reliable.

    MS has been trying to bury it ever since, probably because it plays too well with other (read: non MS) DBs, but they can't make it go away. If you're not doing any really fancy scripting it might fill the bill. I wrote a fairly sizable intranet app largely in IDC/HTX, with an occasional excursion to Regina REXX/CGI and Servlets just to make things interesting, and it's been fairly stable for three years now.

  • IDC/HTX is not being supported my MS going forward. I am pretty sure that support for it is gone under IIS4, and most certainly under IIS5.
    That's news to me. Can you cite a source at MS on that, or are you shooting from the hip?

    It's only an ISAPI DLL; if they're not binary compatible there are a *lot* of things that are gonna break.

    As for the ASP development tools...oh, my goodness. the mind boggles.

    I used Notepad. *grin* The conversion tool is part of that "bury it" effort I was talking about. A lot of cool things escaped (rather than "were released") from niches in the NT development organization just as NT 4.0 came out of beta. Most of them have been sanitized from the documentation, but can be found in the bowels of the NT Resource Kit, especially it's early incarnations.

    By all means, go for ASP/RDO then...stability issues....quirky problems...*and* the marvelous tools, that's certainly a combination you can't beat...:-)

  • And a small postscript..I started with the caveat "if you're wedded to IIS". For those not enamoured of such a misalliance, Servlets and/or JSP look *very* attractive. Why sell your soul to Redmond?
  • Well, *that's* authoritative. :-)

    Microsoft occasionally lets something good slip out. The biggest problems with IDC are that it's too simple, too reliable, isn't riddled with security exposures and doesn't need any bloated GUI development environments to do the job.

    I'm in favor of anything that lets me work without giving a bazillion dollars to MS for development tools that will soon only be available on a rental basis...as if they aren't effectively that already anyhow.

    The control MS wields over developers though the development tools market is stultifying, and soon the latest generation of "developers" weaned on Visual won't be able to do *anything* without Redmond's approval.

    Truthfully though, there's nothing you can do in IDC/HTX that wouldn't make a trivial JSP or servlet, and if "doing your customers a service" includes application portability, then that's the way to go.

  • This is true with PHP3, which runs as a CGI under IIS. I believe they are addressing it with PHP4.

  • I second that. Although we have had very good results with a complex PHP site (DiskWise.com [diskwise.com]), I often would prefer to be dealing with a more general purpose language, whether it be Perl, Python, Java, or whatever.
  • Yes, I tried it. The results were very poor, but my ASP was very complex. It got confused by the extensive quoting I was doing, and really munged up some of the code.

    I think it might do an acceptable job if you ASP (VBScript) is very simple. Definately try it out yourself with your code.


  • ** Separation of data from the presentation. We're going to allow users to customize and 'skin' the site, so XML/XSL is definitely on our horizion.

    There is a huge amount of value in doing this, and one of my gripes about PHP (which I use extensively for DiskWise.com [diskwise.com]) is that its basic design encourages mixing HTML with code. I know that it is very possible to not do so, but nonetheless that is the "default" mode of operation.
  • Any idea how it compares in scope? From looking at the sites, Zope appears to be a MUCH larger project than Midgard.

  • Cocoon [apache.org] 1.4 has just been released. It's a web publishing framework that uses XML, XSLT, and XSL FO to produce HTML and PDF files. Dynamic XML production is still a bit patchy, though certainly possible and is actually being used on production sites.

    In my opinion, any web page generation technology that does not use XML and XSL to seperate content, design, and logic is a short-term solution at best. The benefits of using XML and XSL are too profound to ignore - seperation of content from design means that it's easy to produce views of your site tailored for the client - be it lynx, Netscape, Palm, even a Flash movie player if SVG ever achieves widespread support.

    Conversly, it's a breeze to maintain multilingual sites. Using XML as both the input and output format for dynamic page creation modules means much more reusable modules and, ideally, language independence when choosing modules. Since XML/XSL aware clients are on the way, it will soon be possible to offload page rendering to intelligent clients and do the processing server-side for dumb ones. Oh, and did I mention that it's open source and uses an open source XML parser, open source XSLT processor, open source source XSL FO renderer, and optionally an open source ECMAScript interpreter? :)


  • It is pretty fast from where I see it, both at home and at work. Perhaps there are network issues between where you are, and where Zope.org sits?

  • Frankly, I've done quite a bit of web programming. Everything ranging from PHP to Perl/CGI to ASP, JSP, CFML, WDDX/XML, EJB - you name it.
    Currently our main site is done on ColdFusion (I didn't program it tho). It handles I don't know how many millions of hits a month and works well. However, it's pretty one sided and while it serves up tons of db/dynamic content, it doesn't get that hard core into the 'application' aspect of a web site.
    The site I did (http://supplies.bispace.com) is a full blown web app. It started 3 years ago using ASP (that's all I had at the time). Now it's a bastard of ASP/VBScript and *many* Java classes that have COM registrations in the NT registry (talk about trying to find a needle in a haystack; MS is *very* hush hush about using Java on IIS. Go figure...). I've made it a specific point to try and program from a non-Microsoft centric view. Which makes me even more of a beliver in *nix and Java. My Java classes will run on an ASP webserver just same as a JSP web server (I've already done this).

    The next version of our Supplies site will be completely re-done in EJB using BEA's Weblogic app server. This may be too hardcore for some web sites, but we have many things we're dealing with:
    - Tying in to existing customers ERP systems (Peoplsoft, JD Edwards, SAP, etc..)
    - Complete server/session failover. Webloigic has clustering at the app level. I could care less about the OS level - that usually brings in too much low level crap i don't need to deal with.
    - Separation of data from the presentation. We're going to allow users to customize and 'skin' the site, so XML/XSL is definitely on our horizion. And in theory, if we created a Swing or Win32 app that could make http calls and parse XML, then we could also have another interface into the same system (yeah, that one's pretty crazy..).
    - Scalability. While NT and ColdFusion have performed well serving up dynamic db content, when you start using a web app - which has to do many different type of things (not just figuring out a date range or whether or not a user posted a certain form element) - the server is going to bear more and more of a complex business logic (or whatever you want to call it) type of hit.
    - Java (see scalibility). For all my experience, Java on the server side is awesome! I believe Java/EJB will scale much better than any NT/COM solution. We'll be trying out Weblogic on some type of *BSD solution.

    So, I guess it really comes down to what is expected of your system. If you don't have much time, then some sort of scripting solution can get results quick. But if you looking for something that might be 'enterprise' strength after a while, then maybe you might need to look a little deeper.

    Also, one good last note: Allaire bought JRun a little while back and I did a lot of beta and eval with that product (results were mixed). But mix maybe CFAnywhere with JRun and you could have the building blocks of a pretty decent portable system.
  • I'll second this. I have used PHP3 but I am primarily a servlet programmer. Being able to really use the OO features of the Java language has made my servlets about 100 times more portable, scalable and extendable than PHP...

    Also, the Servlet API already supports things like advanced session tracking...
  • I'd have to disagree with you there. I find Java much easier to develop in than Perl, plus I find the syntax MUCH more readable.
  • We are developing Hyper Builder, one server-side engine to develope dynamic content.

    You may want to try it out. You create your sites using any text editor and embbeding some HTML tags that are mapped to callback functions. Kinda like server side includes.

    It's functionality is provided by modules that are dynamically loaded at run time. For example, you may create a module that will make it so whenever you put a given HTML tag it gets replaced by a given content (similar to the way Server Side Includes do it). There are modules that allow it to talk with PostgreSQL (and soon MySQL), create polls, message walls, access counters, user authentication, use HTTP cookies and much more.

    Whenever someone requests one of your pages, the parser loads the HB source files and builds the content that gets sent back to the browser. It communicates with the web server via CGI. However, work is in progress to build a threaded standalone server that talks with Apache through a socket. Whenever someone requests a file ending in .hb, Apache (mod_hb) connects to the HB daemon and passes it the request.

    It currently works only on Unix, but there are efforts to port it to Windows and other platforms.

    I urge you to consider it as an alternative for building both big and small sites. It is *far* easier to use than other alternatives such as C, Perl or Java via CGI, PHP and ASP. Sites developed using HB are *far* easier to update, understand and modify. And you can get things done really faster (true both for big and for small sites).

    You can find more information at the following locations:

    Good luck.

    Alejo.

  • But look at it from the point of view of a reader in a hurry. The fact that you said something first doesn't make any difference if there's a higher-ranked posting (for whatever reason) that also says it. There's no point in reading something twice, irrespective of who deserves priority.

    It is, of course, unfair that this might affect your "karma" adversely. You did a good job, and you shouldn't be penalized just because someone else came along and maybe did something better.

    Maybe being marked down as "redundant" shouldn't count the same way that being marked down as "flamebait" should be.
  • PHP is a terriffic system, but with the release of version 4 so close, I can't see putting tons of effort into getting stuff running in PHP3. This isn't really because of compatibility issues - PHP3 code should work near seamlessly with PHP4 - but the newest version will introduce state/session management directly into the language. Right now, you have to rely on other people's session managment classes to do that - there are some great ones out there, but it isn't really worth figuring them out now if they're going to be supported in the language soon anyway.

    That said, I use PHP almost exclusively for web scripting these days. It has a steeper learning curve than CF, but it's also infinitely more flexable.
  • Roxen Challenger [roxen.com] offers some of the features you wrote, and some others.
    It has its markup language (RXML, but an XML-based version is coming up), which is easily expandable (it can use itself to define new tags). It offers quite a lot of functionalities for dynamic sites, without requiring CGIs. Native database connectivity (in RXML, but not only), web-driven configuration, support for dynamic images generation (mainly used to generate graphic texts and diagrams), support for many different protocols (HTTP, FTP, GOPHER, you can even play tetris with it), and can act as an HTTP proxy.
    Oh, it's fast too (the "next version"(tm) has been benchmarked [Warning! I said benchmarked!] serving 12000 requests/second on a double PII/350 running Solaris). It can run either as a single thread or multithreaded. Being a single-process server, it can cache aggressively (no more performance bottlenecks because of DNS). By the way, it has its own asynchronous implementation of the DNS protocol, a nice extra boost.
    It doesn't support WebDAV, but there are products based on it which offer templatized site construction.
    It's written in pike [idonex.com] (it has LPC origins for you MUDders)
  • Hmmm.. If you look further below on here I'm going to be freeing up the code soon :)

    That is very cool. I did notice your post yesterday but didn't have a chance to respond.

    I'm also breaking up the source code so it's easier to read..

    As far as comments go.. who needs comments? :) well I can add those in too.

    I will try to grab a copy of your source when it is released and see if I can make any contributions as far as comments go. I've found that it is sometimes most useful for someone who isn't familiar with the code to figure out what sections need comments based on what isn't apparently obvious. Getting the benefit of not being too close to the code I guess you could say.
    I also have some interest in adding support for more of the databases that are supported by PHP.

    Since no one is paying for it I'd rather see it has a problem for Microsoft than just a program no one uses so I am making the next release free...

    I think that being able to free people of the shackles of ASP proprietariness is an important enough thing that I'd be willing to help out even with something that I don't have a personal need for. I also think that PHP is cool enough that anything that helps it become more popular is a good thing.

    I think that there are still some opportunities to make money with this thing if it becomes popular. Perhaps writing a book or charging for support. You might even just be able to personally write your own ticket into a really cool job somewhere if that is what you want.

  • We also applied CF to a legacy client server system running 300,000 lines of custom C code under SunOS and Sybase 4. The system had not been maintained and was due for a $1.4m upgrade for Y2K. This money was to port the code to Solaris 2.7 and Sybase 11.4 with no new functions or upgrades for the users. Yet another example of Y2K money squandered foolishly.

    No kidding. I wish I could find a few contracts like that. $1.4M for such an easy porting job (I do stuff like that all the time) is basically highway robbery.

    Porting 300,000 lines of C code to such similar platforms is at most a nice mid sized project that should take 1-3 decent developers 3 to 6 months including debugging and testing, assuming your contention of no new functionality. That comes out to something like $333 per man hour figuring conservatively.

    Frankly, I think one well experienced developer could do all of the porting work in a few weeks, and get a couple of people to help with testing. I've done jobs like that in that kind of time on code I didn't even write to begin with, so this vendor with presumably familiarity with their own code should have a leg up on it.

    We quickly prototyped a CF solution and determined that the entire baseline could be completed, with major enhancements, with 30,000 lines of HTML and CF "code" in approximately 6 months. The original vendor concurred, but still wanted the $1.4m, and another $1m and a year to upgrade.

    $1M for only 28,000 lines of CF code should yield a pretty damned good profit too, for that matter.

  • by SoftwareJanitor ( 15983 ) on Wednesday September 22, 1999 @08:42AM (#1667139)
    I have corresponded with the author of ASP2PHP (which did seem to do a good job of converting some ASP code a friend of mine had -- I don't use ASP, so I can't give that much of a testimonial there).
    Although some people will probably not like his (definitely not open source) licensing for ASP2PHP, he did release the source a while back, so it may be possible for you to fix the problems you encountered. Getting him to accept the changes back may be somewhat more problematic, as he is a bit picky about how he will take things (he doesn't like diffs). Also the code isn't commented as well as I'd like to see for other people to work with it (something the author did not dispute, as he hadn't intended originally to release the source).
    He also offered to look at ASP code that wasn't converting properly, so if you are willing to send him examples, he may be able to enhance the product so it would work better for you.

  • Sitecopy [lyra.org] is a very nice little site-management tool that implements WebDAV uploading today.

    It comes in a command-line version, or with a GNOME [gnome.org] frontend.

    (I don't know what you mean about "drag-and-drop management", I haven't used IE5 yet. But it sounds cool. :^))

  • Are you testing the full CF package or just the Linux 'stub'?
  • One of the reasons (I feel) that CF is RAD is that it was designed specifically for the web. It wasn't 'C' put on the web or 'Perl' for the web.

    Hence it integrates beautifully with HTML, stylesheets etc. And as jake01 says, this makes it incredibly fast to develop web based applications.

    As for running PHP and CF on the same machine, because IIS will use different services and/or CGI programs to interpret the two (i.e. .php3 files by php and .cfm files by ColdFusion) it should be okay. The only problem may be NT and/or IIS itself. I'm not sure how well it would handle interpreting different types of pages but shouldn't be a major problem.

    You may be interested in the upcoming release of CF 4.5 for Linux. This is coming out soon (currently in Beta 3), and I'm sure that Linux w/ Apache will be able to handle two seperate app servers much better than NT can.

    Simply Senzuri

  • I'm very interested in this too.

    I have been working with coldfusion for about 4 months, every day, all day. As much as I feared coldfusion when I first started it hasn't been that painfull. I have a few minor gripes, you can't pass structures to custom tags, cfscript seems about half finished (no functions). These aren't that bad though, you can always pass WDDX to a custom tag and deserialize it. The biggest complaint I have isn't about coldfusion at all but access.

    We are now looking towards migrating away from NT,IIS and access. Last time I glanced at php it seemed perfect except for a few problems (no DBI) but I'll have to take a serious look at zope.
  • I'll be straight up and say that I have never used Cold Fusion. That outta the way, I gotta ask Why does anyone? To you use Cold Fusion you need a fast machine with lotsa RAM, Windows NT Server, Oracle or MS SQL Server and we are talking about 12 grand US for even a small implementation.

    More importantly, CF seems to be little more than Yet Another Scripting Language that sits on top of a database server and whose only distinguishing feature is that has some bundled apps. Basically a glorified Front Page for database apps.

    The competition? PHP3 plus MySQL and a Linux box will set you back less than a grand, has lots of available code out there, is very easy to work in, etc. Am I missing something really important about Cold Fusion? Why would folks possibly want to throw mega bucks at something that has very inexpensive and flexible alternatives readily available?

    I use PHP lots these days - www.samplelibrary.net [samplelibrary.net] is done solely in PHP3 as is my under construction FAQ engine (FAQ-U [industrial.org]). How would Cold Fusion make my life better than what I use now? =)

    Cheers

  • Just for clarification, everything I stated about Cold Fusion was garnered from perusing their website. Saying I have not used it is not the same as "I have not looked into it". If you know of somewhere that explains why Cold Fusion is cool without all the vapid marketing (i.e. actual content), please point me to it.

    With respect to the cost issue, I would have thought it seemed obvious but if you need it spelled out here goes:

    Cold Fusion - one to three grand US
    Windows NT Server - about a grand for a reasonable license
    Microsoft SQL server - 10 grand for a basic setup
    PC powerful enough to run all this - minimum a grand

    Costs more if you want to run Oracle or Solaris. For most web applications, PHP and MySQL is just fine and will cost you a total of about a grand to set up.

  • Ok Mr. Smartypants. Since you want to resort to insulting my spelling (which usually isn't that bad) instead of dealing with issues or answering my questions here goes. . .from the Cold Fusion site page [coldfusion.com]:
    ColdFusion uses 32-bit ODBC drivers or OLE DB to communicate with a wide variety of relational database systems. (Note: the Enterprise edition supports native drivers for Sybase and Oracle.) It has been tested for compatibility with the Microsoft ODBC Desktop. Drivers, which are bundled with the product: Microsoft SQL Server , Microsoft Access, Microsoft FoxPro, Oracle Borland Paradox, Borland dBASE, Microsoft Excel, Plain Text Files
    Now, from what I understand (and do correct me if I am incorrect) Cold Fusion is not a database system unto itself. You wanna do database queries you need a database server sitting underneath it (i.e. it is just a scripting language system with bundled apps). Access is not an option - it is solely single user. Use that on a web server and you are gonna get corruption. So that leaves real database systems such as SQL Server or Oracle since we are talking NT. Along those lines, unless you wanna play footsies with various legal departments you need the right site liscenses no? That is minimum 12 grand and that is being conservative.

    So unless the Cold Fusion site is terribly misleading (possible), you still need a database server if you want to do database stuff. If you don't need this then what exactly is the point of Cold Fusion? I'm not trying to be obstinate I just don't see the purpose of the thing - it really appears to be nothing more than hype. If you know of some site with a decent overview that shows differently point me at it.

  • by CAB ( 19473 ) on Wednesday September 22, 1999 @08:14AM (#1667147) Homepage
    Compared to Zope, PHP is merely a very nice scripting language you can embed in your pages, so to speak. I really dig PHP for it's own uses, though.

    Zope, on the other hand, is very impressive!
    Object Oriented, tight, finegrained security model, very dynamic, runs on several platforms, Python, connects nicely to databases.... OpenSource!!!

    Zope has an extremely high Feel Good Factor(tm) (a Jamiroquai term); in fact, it's very addictive!

    Once in a while you come by a ware and this strange, warm feeling fills you up... these people have created a product with a lot of brains in it and behind it... everything is good!

    Zope is of this kind.

    Btw. you can get nice commercial support from the creators at http://www.digicool.com/


    Best regards,
    Steen Suder
  • by urizen ( 19538 )
    Since you are on NT/IIS I would also
    recommend evaluating JRun (http://www.allaire.com/jrun). Interestingly
    enough it is now an Allaire product.

    JRun is a servlet/JSP engine that supports almost any web server OS configuration. Don't be scared off by Java, modern VM's scream. Here's a comparison of JSP and CF you might enjoy:

    http://people.sigma6.com/~jsturm/cfjsp.html
  • I can recommend that book also. It is in full on his webpage, but the paper version reads easier. It also comes with nice pictures, that have nothing to do with the topic of the book whatsoever, but are nice to see anyway. But seriously, lots of the thoughts and experiences in that book are worth while. In any case, Phil is a gifted writer, not afraid to expose stupidity if he encounters it somewhere.
  • And it's proven to be a great technology. If you're working on something that won't be publically released for a month or two, wait for PHP4 - the features and speedups are incredible. My recommendation is start using PHP4 beta2 for your business logic app, and as that becomes stable, start switching over your CF stuff to PHP. CF has some benefits, and it's certainly better than ASP (shudder), but fundamentally, you don't have the source code, so if something goes wrong, you're screwed. Period. I've been doing web development for over a year and a half, most of which was ASP, with some CF, and now recently pretty much all PHP3. My clients don't want to hear why the site isn't working... they just want it to work. And time and time again, I've had bizzare problems with ASP where I have *no idea* what went wrong. And there's nothing I can do to fix it.

    Also, if you're switching over to PHP, buy a cheap box, throw linux on it, and use it for testing and getting familiar with linux and PHP... and try using mySQL or mSQL, rather than msSQL... MS's SQL server proved to be a whole new kettle of crap while I was using it.
  • If you're a big PHP fan, you should check out Midgard (at www.midgard-project.org [midgard-project.org]). It provides some sweet content management and administration features (very similar to some of Zope's capabilities), but is based on a slightly-modified version of PHP. They have experimental ODBC support, and that should be solidified very soon.
    --JRZ
  • I won't knock ColdFusion too badly, my company has a large investment in it also. Thankfully since they brought me in I have introduced them to PHP.

    I run PHP on the Unix servers while CF is happy on the NT boxes. As far as the failover support in PHP, that is really dependant on your web service itself since PHP on NT is run as a binary such as Perl is.

    Handling hits, I'd say that PHP & CF come out about the same. Just finished helping a friend convert from NT/ASP to Linux/PHP and he was very impressed, previously he had been handling up to 400k hits/day but anything above that and the servers would start dropping out and having faults. With his new combination he was ramping up to 900k hits/day without any glitches.

    Yes...I am biased towards PHP and I look forward to the new features in 4.0, as a control freak I like to dig into the source and grow my own features.
  • I went to one in Pasadena, and another at UCLA that was the pay-per-view version. Both had very similar content. I've read the old book and the new, and am a regular on the wtr section, yet I still came away with more than I expected. It's amazing once Greenspun gets into the backend of the site - stuff you'd never see. The code quality is even better than I ever considered. If it's the free one - go!!! If it's the ppv, it's still probably worth it. This guy really gets it.
  • IDC/HTX is not being supported my MS going forward. I am pretty sure that support for it is gone under IIS4, and most certainly under IIS5.

    With ASP/ADO and ODBC, you can connect to most major RDBMSs anyways.

    Microsoft had even supplied an IDC/HTX -> ASP converter.

    If you are going to do the scripting under IIS, you are best off with ASP. The environment has some stability issues, and you end up with quirky problems, but you can't beat the development tools.
  • I can't seem to find an MS quote on that. However, I do know that MS is supporting ASP and not IDC/HTX going forward. We did conversion work for clients trying to get away from IDC/HTX.

    Anyways, why would you develop anything using an obscure technology that dates from the earliest days of IIS and MS is not supporting?

    As for my comments about the development tools - Visual Interdev and SourceSafe are excellent if you have to develop for IIS.

    In my experience, ASP (mosty IIS actually) have had several problems that have required hotfixes, etc. to get working. Welcome to Microsoft.

  • I did manage to find an article from MIND from 1997 that states:

    IDC was intended primarily as a short-term solution. Its functionality has been completely superseded by Internet Information Server 3.0 (IIS) and ASP, and is no longer officially supported by Microsoft.

    You could develop using IDC, but are you really doing your customers a service?

  • There is nothing wrong about passing structs to custom tags. Contact me off this forum if you want some help in that area.
  • I have personally not used Cold Fusion or Zope. But, I require *nix based solutions doing basically the same stuff you have done.

    I evaluated offers with simillar requirements recently.

    As for Zope, it looked to me to be a simpler language than PHP, although powerful. I think it is good for dynamic web pages, but big web apps (such as the sort I create) are out of its scope.

    The result of my evaluation was that I'd recommend Zope here (after using it for some time now). The big web apps are what zope seems to be good for!

    The only thing to say against it is: be careful when designing you app. You can do too much, a few rules from the language classes (e.g., lexical scoping) have been forgotten. You have to bring them back by policy. But that in turn is quite possible.

  • I have been developing in cf for quite some time, And my Biggest site is TOTALLY dynamic, everything except the images are in the db. We do on average 70k sessions a day. All of cf/iis/nt. So i doubt that cf cant handle load cause it is. Now running cf on a unix box was a whole different story, they use to use an emulation library to get it to run on unix which was just butt-ugly. btw the throughput over the nic card for the site is averaging 220 kb/s. constant. Again I love linux/unix/bsd etc etc etc. But dont bash something beacause you havent done it.
  • by pdstrnad ( 42215 ) on Wednesday September 22, 1999 @05:00AM (#1667177) Homepage
    If you can't wait for PHP4, then check out PHPLIB [netuse.de], which is one of the session management libraries for PHP3. Besides the session management class, PHPLIB also offers other classes for things like authentication, permissions, building forms and validating input, and a ton of other stuff I can't think of now.

    Yes, it does take a while to figure out how PHPLIB works, but once you've figured it out you'll be hooked. I highly recommend it.

    As far as Cold Fusion goes, I wouldn't recommend the Solaris version. We developed one of our sites in CFML and we had nothing but problems with the CF server. Hopefully the Linux version will be more stable.

    -Philip
    http://www.buymp3.com/ [buymp3.com]
  • PHP is a great concept for a language - being entirely internet oriented it makes code more compact than, say perl CGI.
    Gosh, I don't think so.
    use CGI ':standard';

    print header(), start_html();
    print "You asked for ", param("COUNT"), " items.";

    As you see, it's so easy even a script kiddie could use it. And they do.

  • by Tom Christiansen ( 54829 ) <tchrist@perl.com> on Wednesday September 22, 1999 @11:34AM (#1667184) Homepage
    I've had to deal with nasty CGI Perl code written by other people that I was barely able to read, much less figure out how to change without breaking the whole thing.
    It's a shame that this is true, but you're right. Perl is so easy to use that people who have no experience in designing programs for long-term maintainability can just crank out any old thing. And most of the CGI world falls into that category. I don't know a solution beyond making a programming language too hard to use for people who don't know much about programming. And that won't win you any friends.

    On the other hand, many of the mod_perl applications I've looked at have been sophisticated and clean. They've actually been designed and structured. They're a pleasure to read and to maintain. And they're written in the same language as those CGI scripts from hell that the script kiddies mutilate. Yet it seems like it's galaxies far removed.

    Interesting, eh?

    I believe this is saying more about the average CGI script kiddie versus Apache mod_perl hacker than it is saying about Perl. But yes, it's easy to write bad perl code. I guess it's easy to write bad C++ code too, but the barrier to entry is higher.

    I don't know that there's ever been a language written in which it's been the least bit hard to write bad code. If you outlaw bad code, only outlaws will code badly. :-)

  • by Earlybird ( 56426 ) <slashdot.purefiction@net> on Wednesday September 22, 1999 @06:28AM (#1667187) Homepage
    As for Zope, it looked to me to be a simpler language than PHP, although powerful. I think it is good for dynamic web pages, but big web apps (such as the sort I create) are out of its scope.

    Certainly not. First of all, Zope isn't a language -- Zope's DTML language is just a small component in a large system. You don't even need to use DTML in order to reap Zope's benefits.

    Secondly, Zope's strength is its open-ended, object-oriented nature. Comparing Zope to PHP is largely meaningless. PHP is a preprocessor; Zope is a middleware platform. Zope has been specifically tailored for enormous, complex, high-volume web systems.

    With the recent introduction of the Zope Enterprise Objects [digicool.com] (ZEO), which will let you set up multiple object database servers that may mirror their data through replication, Zope grows to even higher planes of scalability and capacity. Combine ZEO with round-robin DNS and you have a good load-balanced failover solution.

    A little research into what Zope really is might have helped. You're just spreading disinformation.


  • I have written applications using ColdFusion, PHP3, ASP and now Java servlets. Once you fully appreciate the power of servlets; I've never looked back.

    PHP3 suffers from the lack of session management-I know there is an add-on to handle that; and I have not checked out Zend (PHP4) in detail, so that might have changed. PHP4 supposedly comes with built-in database connection pooling, it sounds great.

    My work with ColdFusion got me a new car, but I've never liked ColdFusion. Yes, CF is probably the easiest server-side scripting solution. But I have never been satisfied with its performance; which may have more to do with NT than CF. CF database connectivity functions are rather simplistic and do not give you much flexibility, IMHO. You can only do so much with s.It might be good enough for use with an ultra-simple database like Access; but once you start using a more complicated database like Oracle or MS SQL Server, you will need more complicated database access interfaces like MS ADO or excellent JDBC. But then, you can of course use ADO with CF, too.
    By the way, you really don't want to get caught running Access as a database if your site gets /.'ed, or otherwise accessed very heavily. Things will get very ugly. Very ugly.

    In my opinion, servlets are the way to go. Download Jserv and Apache, or one of a number of servlet engines for IIS, if you have to run on IIS & Windows NT. Get the O'Reilly servlet book, and start experimenting. You get built-in session management, excellent database connectivity with JDBC, access to all those free Java code around, and a lot of other goodies too numerous to count. When Enterprise JavaBeans become more popular, you will have a very good distributed object technology in hand, too.

    I kind of like ASP, but I think Slashdot is not the right place to confess this, so I will stop. It's a pity it runs on NT only-there are a bunch of ASP solutions for other platforms as well (Chili ASP comes to mind), but frankly I'm not sure if you still have access to COM on those platforms. Almost everything that's useful with ASP are COM objects.

    In a nutshell:

    -If most of your work involves simple database query pages and simple dynamic pages that have to be done quickly, I don't think any of the server side scripting languages will make any differences. ASP, PHP and CF should be equally fine. You probably will not be dealing with fancy features like session management or database connection pooling with these anyway.

    -If you need to do more serious applications which will experience high traffic, and complicated database operations, consider servlets, or COM objects with ASP, if you definitely have to use NT. If you use COM and ASP, consider writing the objects using ATL for the highest performance-in terms of performance, it is only second to ISAPI DLLs with IIS. However you will find it very easy to write COM objects in VB as well.

    Moving to a real application server like open source Enhydra,Locomotive or IBM WebSphere will be even better in the longer term. They have some pretty impressive infrastructure for use with servlets, and they are very robust, too.
  • by RickyRay ( 73033 ) on Wednesday September 22, 1999 @04:15AM (#1667196)
    Everybody seems to be focusing just on Zope, PHP, Perl, and ColdFusion. What about:

    (1) Midgard (www.midgard-project.org). It layers on top of PHP, adding functionality, remote administration, more code generation, etc. They plan to do an NT version soon (might be more a matter of just compiling it than doing any coding).

    (2) Java Server Pages. They let you embed code into pages the way you do with PHP, ASP, and the rest. But since they're Java, you don't need to learn a new syntax, and you're guaranteed to be able to do anything (remember: Java can also use Perl and C/C++ modules, so anything is fair game). And apache.org supplies a free engine for it. I use JSP's regularly, and they're great.

    (3) Servlets. Yes, they're useful and powerful, and standard syntax.

    (4) Cocoon (ava.apache.org/cocoon/). It's a project using COM, XML, and XSL, and will probably be the most powerful framework around (but I want to wait to see anybody use it before I try; it's difficult to be first, since there's nobody to ask how to do it!).
  • by andyschm ( 74188 ) on Wednesday September 22, 1999 @08:52AM (#1667198)
    PHP is a great concept for a language - being entirely internet oriented it makes code more compact than, say perl CGI.

    I use PHP very seriously. I also use a Linux platform, and would strongly recommend that.

    PHP3 has some big problems. 1) effeciency is not very good, especially noticeable on a large website. As I understand it, PHP3 has no capacity to cache the result of parsing code. Thus everytime a function is called or a file included, the parser must re-check the code. 2) OOP sucks! Reference support is extremely bad. Be prepared to undergo major hacks to get OOP working with PHP3.

    I have used PHP4 beta 2 for over a month now with no glitches. It is a wonderful thing. OOP actually works great! And the parsing engine caches results (similar to Perl). Also lots of other handy stuff has been added... including output buffering (enables you to send HTTP headers even after HTML output) and a bunch of other functions that you will see in the PHP3 manual that look great and have a footnote saying "added to PHP version 4".

    As I understand the licencing for PHP4, PHP4 itself is open source and free. Something called "Zend" is the parsing engine for PHP4, which you must pay for if you intend to take the Zend code and use it within a commercial application.

    There is something called PHPLIB available for PHP3 which takes care of a lot of web authentication, page rendering, etc with some high-level object code. I looked at PHPLIB and decided not to use it because use PHP4, and I prefer to know every little detail of how my code behaves. However, PHPLIB gives a good structure for how a complex PHP-driven website can be built, so it is a good starting point for anyone.

  • by Cos ( 75890 ) on Wednesday September 22, 1999 @04:29AM (#1667206) Homepage
    We developed our sites in PHP3 with MySQL on FreeBSD, and we're very happy with them. However, we've recently been playing with a couple other tools that have really piqued our interest.

    ZOPE: Very nice development interface, easy to add functionality using python, XML support, good cross-platform ability. The object-based development platform takes a little getting used to, but is extremely powerful and convenient.

    See An Introduction to Zope [devshed.com] for a very good overview.

    PHP: Can do just about anything. Great database support. We've had no performance problems due to php at all. Run it as an apache module, of course. I have not used it much on Windows, but PHP4 promises to have excellent Windows support.

    We have a number of articles, tutorials and docs about PHP at DevShed [devshed.com].

    APACHE JSERV: Efficient, powerful, mature. Apache talks to "Servlets" that do most of the work. The servlets stay in memory, no new processes are forked. Multiple servlets may be used, I believe across multiple servers if necessary. Session management is included. It's all Java. Apache Jakarta will also include Java Server Pages (JSP), a strong competitor to PHP and ASP.

    ROXEN: Similar to PHP, written in Pike, a C-like object oriented language. Easy separation of layout and content, easy database integration, very efficient. This one includes its own multipurpose server (web/proxy/ssl/ftp).
    See Introduction to Roxen by Kai Voigt [devshed.com] for more information.

    We're still sticking with PHP for now, but looking most seriously at Jserv for the future.
    Our #1 qualifier:

    OPEN SOURCE - all of the above solutions are!
  • Something you may wish to consider is Allaire's announcement that they will be releasing ColdFusion for Linux in November.
  • by Ledge Kindred ( 82988 ) on Wednesday September 22, 1999 @04:12AM (#1667209)
    Is there a reason why you want to use PHP on an NT/IIS platform for any reason other than "it's just too damn cool"? I've used PHP on Linux with Apache and have had lots of luck with it, but that's because it's designed to work on UNIX-y boxes with Apache, for the most part. Trying to wedge it into an NT/IIS situation is, IMHO, Not A Good Idea. If you're using Cold Fusion and comfortable with it, keep using it. Don't switch for any "Cool Factor."

    If you wanted to switch, I would highly recommend switching over full-scale and rebuild those NT boxes as Linux boxes, use Apache and PHP or mod_perl or what have you.

    You might also look into doing servlet programming with Java. JDBC offers an excellent interface to databases and the advantage of going Java is that, at least with JDK 1.1, you really can move your code from the NT box to a Linux box when NT buckles under the load, and from there to a huge 64-processor Solaris box when the Linux box can't take it any more and it will all work essentially unchanged. (Write-once-run-anywhere works for the most part as long as you stick with straight JDK1.1 stuff and don't use too many third-party add-ins, or at least stick to add-on libraries that are 100% java.) IBM's JDK for Linux is quite high-performance and remarkably stable for what they call an "Alpha" version. (You can find it at www.alphaworks.ibm.com)

    A warning about Java servlet programming -- Java is a highly structured language and if you're into the kind of "quick kluge" that languages like Perl seem to be designed to handle, or the "quick one-off" that PHP excels at, you're going to have some problems moving to Java servlets which requires a lot more thought and "engineering" to get a good design. The advantage is, at least in my experience, going the Java route winds up with much more maintainable and extensible codebase.

    This is not intended as a poke at PHP or Perl, just that those two languages are really designed to do stuff "quick-and-dirty" and therefore are very easy to write nasty code -- lots easier than it is with Java. (although you can still write nasty code in Java.) I'm speaking from experience as I've written nasty code in PHP and had to try to clean it up into some sort of maintainable form without a lot of luck once the codebase gets to a certain size, and I've had to deal with nasty CGI Perl code written by other people that I was barely able to read, much less figure out how to change without breaking the whole thing.

    -=-=-=-=-

  • I've coded both extensively. If you're running NT, use ASP/SQL Server 7.0; PHP under NT isn't there yet.

    CF doesn't do everything I need and it's damned ugly.

    Linux: PHP 4 and Apache.

    ASP:

    Pros: ASP makes better use of record sets through the recordset (surprise!) component and the use of sessions variables is much more intuitive.

    Cons: NT

    PHP:

    Pros: Linux/Apache and a much wider range of support for inexpensive (and expensive, if you like) databases.

    Cons: None

Politics: A strife of interests masquerading as a contest of principles. The conduct of public affairs for private advantage. -- Ambrose Bierce

Working...