FW: Bugzilla rewrite in PHP

Thought this was amusing and the list might like to comment on it. :) Chad -----Original Message----- From: Stephen Clouse [mailto:stephenc@theiqgroup.com] Sent: Tuesday, November 21, 2000 1:11 PM To: mozilla-webtools@mozilla.org Subject: Re: Bugzilla rewrite in PHP -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > If you were given the task of rewriting Bugzilla from the ground up, would > you keep its existing Perl/CGI based format, or would you use a web based > scripting language, such as PHP? PHP makes for a nice toy language for sites with simple programming or Web/DB interface demands, but to me the whole PHP system seems purely whiz-bang. It becomes more apparent if you look at their function reference, where the only thing missing seems to be a RFC2324-compliant coffee maker interface. It's caked-on layers of function sets with an obvious lack of direction or design. Brooks described second-system effect; this looks more like sixth-system effect. Feeping creaturism is definitely the controlling factor at work. The mutation rate still seems to be very high. It also lacks something crucial to Bugzilla, a consistent database interface. Oddly enough, PHP supports object-oriented design, but all the core routines are function-based. Three different databases, three completely different function sets. Having to deal with mysql_*, pg_*, Ora*, and OCI* (yes, even the function name styles are inconsistent) is not particularly conducive to the goal of making Bugzilla database-portable. Not to mention that an Oracle 8 port under this system, having nothing but the raw OCI available, introduces a whole new level of pain. Of course, you could write an abstraction layer for PHP yourself, but Perl has DBI already. You also lock yourself into their supported architectures. I believe this was the reason mod_perl was argued against a while back (being essentially an Apache-exclusive feature). PHP's support seems to be quite a bit broader, but I can't really be sure (the innavigability of their Web site doesn't help the research much). And you're still forcing the installation of Yet Another Component -- PHP is popular, but it's in no way as defacto as Perl, which seems to be as prevalent as sh anymore. Keep in mind who's going to be installing and using Bugzilla -- I can almost guarantee you're going to see far more corporate hackers already entrenched (not necessarily by their choice) in a hardware/OS/backend system (not necessarily being their choice). Don't just assume they can pop in their RedHat CD and have Apache/PHP/mySQL all set up in a single command. PHP certainly wasn't designed for large-scale or long-term project maintainability, since the "script-in-page" concept pretty much defeats effective code reuse. As a case study, take a look at SourceForge, which is an excellent and functional system that deserves praise, but if I were asked to take over that codebase, I believe I'd opt for the execution instead. There are 298 .php files in that thing. At least half of those are actual HTML pages, and each one seemingly has to import about twelve other .php files before it can even start to work. This is klugy at best, and other large projects built around PHP don't look much better (some look worse, even). The current Bugzilla design isn't much prettier, which is probably why the rewrite is being considered. Things need to be centralized, which is easy to do in the old CGI paradigm, and especially easy with Perl. Perl is easy to maintain so long as you code it that way. Don't feed me that ancient argument about Perl resembling line noise. I'd keep going but it's time for lunch. I suppose at this point I don't have to mention "I think it's a bad idea" :) - -- Stephen Clouse <stephenc@theiqgroup.com> Senior Programmer/Systems and Network Administrator The IQ Group, Inc. <http://www.theiqgroup.com> -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.8 iQA/AwUBOhq6zwOGqGs0PadnEQJawQCgom/d+OB06ujvvdvT6FG0lb6xtwwAoII0 6BGna8Vgv6gJeK97rVLy132u =QYNc -----END PGP SIGNATURE-----