This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: Bugzilla rewrite in PHP From: "Stephen Clouse" <stephenc@theiqgroup.com> Date: Tue, 21 Nov 2000 12:11:29 -0600 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" :) === Subject: Re: [PHP] FW: Bugzilla rewrite in PHP From: "Stephen Clouse" <stephenc@theiqgroup.com> Date: Tue, 21 Nov 2000 20:01:06 -0600 BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I suppose this will teach me to use that "the following is my very conceited opinion" header more often. I also must have become confused and accidentally punched the hole to grant permission to have the post forwarded to god-knows-where. Either that or I voted for Gore, or something. Someone asked for opinions concerning *the Bugzilla project* and I related my opinions in that context. Why the hell some bonehead felt it was necessary to carry it over to a PHP advocacy list is beyond me. But I seem to be stuck now. > Yes, there are different functions to access different databases. > This is what, imo, gives PHP it's flexibility. The databases are different, > and have different functionality, and you should be able to > access the specific features of each. OTOH, we, as most people, > have a db abstraction class that handles most of the routine stuff > for us. nextrow(), query(), open(), close(), etc. Changing databases > will generally only entail writing new code for those functions, > and the main code will remain exactly the same. OK, so DBI has > this predone - PEAR does too, although try to get info on it (or use > it at an ISP) and you'll have an uphill battle. Once you write it, it's done > tho. *PORTABLE* to other projects (the seeming opposite of the > criticism that you're locked into 'code in page' architecture). So some people create PHP modules. I wouldn't doubt that. But these things hide where? Where's the PHP equivalent of CPAN? You can't hardly work with Perl without knowing what CPAN is, it's discussed in just about every perl manpage and book. Resources like that should not go very long without being prominently mentioned. But even then, I'd have to say that you're still relegated to the inelegance of copying that module everywhere you need it, rather than sharing it from a central module library (at least, there is no language-level facility for this - -- certainly I could throw something together on my particular machine to simulate the Perl @INC array, but that would be just my machine). The inefficiency of the former model should be readily apparent to anyone who has either Perl or a /usr/lib directory on their system. And this is where the criticism comes from, everything has to be duplicated, from the library itself to the line that imports it into every page. > True DB *independance* isn't had by Perl DBI. At least, not in my > experience. > I *STILL* need to write sql code specific to the database I'm running on. > If I was connecting to SQL7, I couldn't use 'limit', for example. So how > much benefit something like DBI gives you over something like PEAR > or one of the many homegrown solutions is, to me, questionable. > > <!--#include (Metabase comments)--> :) > > Anyone with more DBI experience care to comment? The problems described are the fault of the SQL servers themselves, not DBI or PHP. I should still be able to code in a way that minimalizes recoding when I'm ready to port to another database, which DBI does. And assuming that I've stuck with SQL-92, I CAN take that same program and just change the database driver parameter, and run it on the new platform. I've done that before, successfully. Honestly, the differences between the syntaxes of the major SQL servers, at least in the realm of SELECT/UPDATE/DELETE, are minimal to zero so long as your schema is properly normalized. And now the consistency of the DBI interface shows its real benefit. The prepare/execute/fetch model of DBI is universal, no matter what database I'm using. I suppose I'm just lazy (I can hear the replies to this now -- God forbid we make you write a PHP abstraction layer). But one still wonders why, with all this database support in PHP, that no one ever considered a standard interface to be necessary. > "PHP's support seems to be quite a bit broader" but he can't tell > because of the website. Well, how else does it 'seem' broader > to him? Word of mouth? Higher visibility? The documentation spits out a whole list of supported Web servers. One has to assume that there's broad platform support there as well, but who knows? Nowhere can I find a list of known working or non-working platforms. > The attack on the design of sourceforce is a redherring, obviously. > "The design of large PHP sites that he sees the code for sucks, > so PHP must suck." Bugzilla sucks too - that's why people are > considering the rewrite. "Well, yes, but..." Come on! Do you always create broad statements where there are none? Geez, and I even started out saying "as a [singular] case study", too. > "the "script-in-page" concept pretty much defeats > effective code reuse." Don't put script in a page then. Use > templates. Easy enough. Document what you preach, then. There's only one method I see in the manual. > "and each one seemingly has to import about twelve other .php files > before it can even start to work" > > Example Perl script first few lines... > #!/usr/bin/perl > use Socket; > use Net::hostent; > use CGI qw(:standard); > use DBI; > use Net::FTP; > use LWP::Simple; > > Hmmm.... looks like they need to import a lot of files before > it can even start to work. Okay, so I'll admit that point wasn't well thought, and more specific to the implementation (SF) than the language. But there's something about it that just makes it "feel" far less clean than importing standard Perl modules. Perhaps it's simply that Perl *has* standard modules. > Sheesh! Could this not be said of CPAN? Not everything in the > PHP manual is installed by default, but there are ways of putting > most of that functionality into the PHP interpreter. I wouldn't > say 'caked-on layers' at all? "obvious lack of direction or > design" to me is CPAN in a nutshell. I love CPAN and think it's > great, but there's very little 'direction' there, imo. People > write modules to solve particular problems and put them > out for others to use. Same in PHP. I don't see how you can look at something like http://www.perl.com/CPAN-local/modules/00modlist.long.html and argue that it has no direction. There seems to be plenty of direction. It's merely an extremely horizontal market. PHP, OTOH, compresses that horizontal market into one monolithic function list. But that's more from the lack of namespaces than anything. One might consider that a flaw, too. It's where the seeming lack of organization comes from, anyway. Even setting namespaces aside, you obviously have the OO support (that is well-documented) -- why aren't you leveraging it as part of the core? Fully function-based interfaces are painful, particularly to my Perl side. Better yet, do what CGI.pm does -- offer both with a simple switch. Huzzah. > PHP is also easy to maintain as long as you write it that way. I didn't say it wasn't. I threw that line out as a repellant toward the inevtiable comment concerning Perl's syntax, which seems to be some kind of end-all anti-Perl argument. > I almost didn't write, except that, if only for the list archives, > this kind of 'reasoning' needs to continually be dealt with. I know > a lot of new people are joining every week and need to be reminded > that just because someone from 'up on high' says PERL=GOOD, PHP=BAD, > it's not true. Precisely where did the idea come that I'm "up on high"? As if I'm some kind of Perl demigod/evangelist. The Perl community at large doesn't even know who I am. I just program for my company, in whatever language is deemed convenient. PHP has plenty of uses, and I do use it where I find them to be simpler than Perl. I don't find projects like Bugzilla to be in that category. And as I said at the top, my "reasoning" was in regards to Bugzilla. In that context, I like to think I'm right (since I've designed innumerable systems of similar scope and scale). You act like I set out to slander the Koran. But anyway, this is all (like the first time around) just my very conceited opinion. If you find it flawed, please call someone who cares. With that, I am done with this discussion (that should have never happened in the first place). === Subject: Re: Bugzilla rewrite in PHP From: Brian Behlendorf <brian@collab.net> Date: Tue, 21 Nov 2000 19:10:48 -0800 (PST) Yay language wars, woohoo! My general opinion is that *any* of the usual solutions people choose can be made to work - perl/cgi (or modperl), PHP, Java servlets, a C module or CGI script, Active Server Pages, whatever. Any of them can be made sufficiently performant. For the right set of developers, any one of them will be the fastest & easiest to develop in. That last sentence is crucial; if the majority of those who develop Bugzilla today are Perl hackers, it's almost silly to consider alternatives. It's only worth switching if enough of the current developer base is willing to adopt a new language - and unfortunately (lifts shirt to show battle scars) sometimes the biggest proponents of a particular change don't stick around to see it through. I would suggest that people not start with "what language do we write this in" - it's kind of like a cook deciding what to make for dinner by selecting his utensils first. Instead, I suggest you focus first on the database schema, and its XML representation; take for granted that there are generally pretty excellent XML manipulation tools in most languages, and a database schema is language-neutral. From there, an information architecture; how should bugs flow through the system? What's the decision tree? Where are the hooks for expandability? Lay it out in a big map. Detail the way different components share their info; HTTP POST? args in a GET query? etc. Decide where auth should reside. Etc. (let us never again see a password in a URL!) Once you're at that point - dare I say that different parts can be implemented in whatever language makes the most sense. Or even in parallel, Perl or PHP. Or it can start in Perl, and reimplement performance-critical pages later in PHP, or even C. Etc. But start with a data model, then IA. As I've posted here about before, CollabNet is sponsoring a new bug database project, written in Java using templates (currently WebMacro, potentially moving to Velocity) and an app suite called Turbine, called Scarab (big, flesh-eating bug from Egypt). Progress has been slow for a myriad of reasons, but one thing that's been very well sussed out is the data model. We are already anticipating having to write conversion scripts from Bugzilla's current schema to this new one, so most use cases of current Bugzilla should be captured, but we'd love feedback. http://scarab.tigris.org/ specifically, the files in http://scarab.tigris.org/source/browse/scarab/conf/ Ignoring the SCARAB_ prefix on all the tables, I think it'd be great if the various bug-tracking tools out there at least attempted to collaborate on a common data model, and correspondingly a common XML format for bug interchange and portability. We'd be very interested in working with Bugzilla folks on this; there's really little point in divergent schemas. Thoughts? Brian p.s. - CollabNet has an internally-forked version of bugzilla we're using on sites like openoffice.org. The two reasons we've diverged have been that we've customized it to work with our authentication model (corresponding suggestion: make authentication orthogonal to Bugzilla), because we needed fine-grained access control (not all bugs are public, access control lists, etc) and because we did a global s/bug/issue/ because we're really interested in using this to track all sorts of issues, not just "bugs". Anyways, the code's available at http://sandbox.tigris.org/source/browse/sandbox/issuezilla/ if anyone's interested. We claim no great advancement. === Subject: Re: Bugzilla rewrite in PHP From: dmose@mozilla.org (Dan Mosedale) Date: 21 Nov 2000 20:05:05 GMT matthew@zeroknowledge.com (Matt Masson) writes: > 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? > > Just thought I'd fish for some thoughts/comments. There was a bunch of discussion about this several months ago when the 3.0 planning first began. Read through the archives for some of those thoughts. There was interest in possibly moving to an application server like Zope, as it seems likely to do a lot of the underlying work necessary. However, one of the goals for bugzilla was for the source code to be easily hackable by lots of folks. To that end, keeping it in Perl would be a real win. Using the HTML::Mason <http://www.masonhq.com> modules would be one way to get a lot of the underlying infrastructure while still remaining a Perl application; I think that's still under consideration. What specific problems is your rewrite intended to address? === Subject: RE: Bugzilla rewrite in PHP From: "Matt Masson" <matthew@zeroknowledge.com> Date: Tue, 21 Nov 2000 15:50:26 -0500 I've been maintaining a heavily hacked bugzilla (with a 2.9 base) at Zero-Knowledge for almost a year now, and as our bug database grows, we've been seeing more an more performance problems. While I'm sure some of the hit comes from the multitude of features and hacks I've added to the system, I'm convinced that we'd get much better performance if it wasn't CGI based. Our biggest bottleneck has been our buglist.cgi page. As a test, I wrote a scaled down version in PHP... not surprisingly, queries that took 4-5 seconds to execute normally were done almost instantly. Now, while these results might not be totally valid because of the missing functionality of the PHP page, it none the less convinced me that the CGI base had to go. Besides the performance issues though, I think a rewrite would help clean up a lot of things. Separating the UI, creating a data abstraction layer, cleaning up the database, and customization/scalability issues could all be addressed if we had a clean slate to work with. [ Maintainability and ease of customization is also a huge issue for us, as new requirements for the bug tracker are always coming in! Having a full time person around to make those changes is fine for us right now, but I'm sure it's not an option for most organizations. ] I wasn't planning on starting a rewrite myself.. just wanted to see what others thought about it in general. The main thing I was wondering was what the best fit would be language/architecture wise. I'm convinced that the CGI has to go.. so if not PHP, then what would work best? I feel that eventually the code base will need a total rewrite, but I'm not saying that now is the time for it. HTML::Mason looks interesting. Personally, I'll work in whatever language fits best for the situation.. if HTML::Mason allows for something that resembles the speed of PHP but keeps the familiarity of Perl, then I'd support it whole heartedly. ~Matt -----Original Message----- From: Dan Mosedale [mailto:dmose@mozilla.org] Sent: November 21, 2000 3:05 PM To: mozilla-webtools@mozilla.org Subject: Re: Bugzilla rewrite in PHP matthew@zeroknowledge.com (Matt Masson) writes: > 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? > > Just thought I'd fish for some thoughts/comments. There was a bunch of discussion about this several months ago when the 3.0 planning first began. Read through the archives for some of those thoughts. There was interest in possibly moving to an application server like Zope, as it seems likely to do a lot of the underlying work necessary. However, one of the goals for bugzilla was for the source code to be easily hackable by lots of folks. To that end, keeping it in Perl would be a real win. Using the HTML::Mason <http://www.masonhq.com> modules would be one way to get a lot of the underlying infrastructure while still remaining a Perl application; I think that's still under consideration. What specific problems is your rewrite intended to address? === Subject: FW: [PHP] FW: Bugzilla rewrite in PHP From: Chad Day <cday@beachassociates.com> Date: Tue, 21 Nov 2000 16:49:31 -0500 This guy basically says what I want to say, more eloquently. :) Chad Subject: FW: [PHP] FW: Bugzilla rewrite in PHP -----Original Message-----From: Chad Day <cday@beachassociates.com> Date: Tue, 21 Nov 2000 16:49:31 -0500 This guy basically says what I want to say, more eloquently. :) Chad From: Michael Kimsal [mailto:michael@tapinternet.com] Sent: Tuesday, November 21, 2000 3:52 PM To: Chad Day Cc: 'php-general@lists.php.net' Subject: Re: [PHP] FW: Bugzilla rewrite in PHP While most of these criticisms are *somewhat* valid, they're valid only to the extent that the person writing them is not an expert in PHP, but rather Perl. The database thing is beginning to bug me, as it is sort of true, but sort of not. Yes, there are different functions to access different databases. This is what, imo, gives PHP it's flexibility. The databases are different, and have different functionality, and you should be able to access the specific features of each. OTOH, we, as most people, have a db abstraction class that handles most of the routine stuff for us. nextrow(), query(), open(), close(), etc. Changing databases will generally only entail writing new code for those functions, and the main code will remain exactly the same. OK, so DBI has this predone - PEAR does too, although try to get info on it (or use it at an ISP) and you'll have an uphill battle. Once you write it, it's done tho. *PORTABLE* to other projects (the seeming opposite of the criticism that you're locked into 'code in page' architecture). True DB *independance* isn't had by Perl DBI. At least, not in my experience. I *STILL* need to write sql code specific to the database I'm running on. If I was connecting to SQL7, I couldn't use 'limit', for example. So how much benefit something like DBI gives you over something like PEAR or one of the many homegrown solutions is, to me, questionable. <!--#include (Metabase comments)--> :) Anyone with more DBI experience care to comment? The PHP site being navigable - yes, valid criticism. It's getting better, but it's a hell of a lot of HTML (menus, etc) every page. "PHP's support seems to be quite a bit broader" but he can't tell because of the website. Well, how else does it 'seem' broader to him? Word of mouth? Higher visibility? The attack on the design of sourceforce is a redherring, obviously. "The design of large PHP sites that he sees the code for sucks, so PHP must suck." Bugzilla sucks too - that's why people are considering the rewrite. "Well, yes, but..." Come on! "the "script-in-page" concept pretty much defeats effective code reuse." Don't put script in a page then. Use templates. Easy enough. "and each one seemingly has to import about twelve other .php files before it can even start to work" Example Perl script first few lines... #!/usr/bin/perl use Socket; use Net::hostent; use CGI qw(:standard); use DBI; use Net::FTP; use LWP::Simple; Hmmm.... looks like they need to import a lot of files before it can even start to work. "It's caked-on layers of function sets with an obvious lack of direction or design." Sheesh! Could this not be said of CPAN? Not everything in the PHP manual is installed by default, but there are ways of putting most of that functionality into the PHP interpreter. I wouldn't say 'caked-on layers' at all? "obvious lack of direction or design" to me is CPAN in a nutshell. I love CPAN and think it's great, but there's very little 'direction' there, imo. People write modules to solve particular problems and put them out for others to use. Same in PHP. PHP is also easy to maintain as long as you write it that way. I almost didn't write, except that, if only for the list archives, this kind of 'reasoning' needs to continually be dealt with. I know a lot of new people are joining every week and need to be reminded that just because someone from 'up on high' says PERL=GOOD, PHP=BAD, it's not true. === Subject: RE: Bugzilla rewrite in PHP From: Chad Day <cday@beachassociates.com> Date: Tue, 21 Nov 2000 17:09:46 -0500 As a PHP/mysql programmer, I -totally- disagree. I use PHP for dynamic stuff all the time and it works like a charm. I'm not sure how you got that impression, because PHP is blazingly fast, especially when joined with a blazingly fast db like mysql, to serve up dynamic content. Chad -- http://www.bangable.com -- one of many PHP/mysql sites I've designed. :P (watches this discussion degenerate into a perl vs. php war) === Subject: Re: Bugzilla rewrite in PHP From: Gervase Markham <gervase.markham@univ.ox.ac.uk> Date: Thu, 23 Nov 2000 00:06:02 +0000 Ignoring the SCARAB_ prefix on all the tables, I think it'd be great if > the various bug-tracking tools out there at least attempted to collaborate > on a common data model, and correspondingly a common XML format for bug > interchange and portability. We'd be very interested in working with > Bugzilla folks on this; there's really little point in divergent schemas. Absolutely. But we'll need to pry the draft schema out of tara and cyeh's cold, dead fingers before we can see if this is possible :-) The common XML format would also be cool. Have you had a look at the current Bugzilla one? Is there a current Scarab one? Gerv ===