RE: [PHP] FW: Bugzilla rewrite in PHP

I would suggest looking at Keystone (http://www.stonekeep.com) as a very successful alternative to Bugzilla. -----Original Message----- From: Dean Hall [mailto:hall@apt7.com] Sent: Tuesday, November 21, 2000 2:37 PM To: Chad Day; php-general@lists.php.net Subject: Re: [PHP] FW: Bugzilla rewrite in PHP The guy has some points, but I think that good developers can overcome the "faults" he talks about. In any case, I think PHP is a much better option for web applications than old CGI. > 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. Interesting. I've found that many of these functions aren't available (for better or for worse) unless I have specifically compiled PHP for use with a specific module. You can keep your module base pretty small if you want. > > It also lacks something crucial to Bugzilla, a consistent database > interface. Er, ever heard of PHPlib? I'll admit it's not my first choice, but it IS a consistent database interface that's very well-supported. I'd like to see an object-oriented database interface in PHP myself, but PHPlib is easy enough. > 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). Eh, no reason to use the website as ammunition against PHP itself. PHP is well-supported on many platforms. 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. LOL. Have you heard of RPMs? In any case, it took me a half-an-hour to get Apache (with mod_perl, PHP, and other modules), PHP, and MySQL compiled from scratch and running. > > 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. I'll admit that OO support in PHP is a bit lacking, but I see no major disadvantage from OO in Perl (although many small ones). You can build a highly modular and centralized web application with PHP classes and mySQL; I've done it. > 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" :) I adore Perl, but I think that Bugzilla would be much more maintainable and implemented faster in PHP/(insert your DBMS here). Dean. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net For additional commands, e-mail: php-general-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net