On Monday, 7 January 2002, at 15:55:43, Jesse Erlbaum wrote: > > CGI is a completely valid (and often preferable) foundation on which to > build sophisticated and important web applications.
Are you referring to the set of environment variables that are the essence of CGI? It is completely valid but I wouldn't go as far as to say it is preferable. > > When someone says that CGI is not for "serious" applications, what they > probably mean is that the old-fashion method usually associated with CGI > applications involving spawning sub-processes for each request is a > performance bottleneck, to be avoided. I fully agree! IMHO, use CGI but > use it in an embedded fashion via something like mod_perl. The only reason to use CGI is due to this subprocess spawning method -- to get the information from the web request to the spawned application as there is no way to pass it directly. Native mod_perl allows you direct access to the web request as stored in memory by apache. I hear you saying "but that isn't portable across APIs" and you are right. So use a programmatic abstraction of CGI (custom API, essentially) which provides the required information from the available source, be it mod_perl Apache::Request object, CGI environment or whatever IIS uses. I feel that is the most flexible approach, and it allows you to do neat things like run a CGI::Application inside of another. Speaking of mod_perl, I was wondering if there is a generic PerlHandler for bootstrapping a CGI::Application. > Anyone who tells you that these performance problems are unique to CGI, or > that they are only solved by using some other technology does not know what > they're talking about. Period. > > Once you get beyond the run-time performance issue there are many, many good > reasons for using CGI as the bases for your web applications. For starters, > it is easy and familiar for most programmers. CGI is also very > cross-platform compatible. IOW, a CGI application you write to run on a > UNIX/Apache server will quite likely work just fine on a Windows/IIS server > with little or no modifications. See above :) You then go on to make several good points that I can't really argue with :) > > Mark made an important point about understanding what CGI is, and is not. > CGI is just a standardized Application Programming Interface (API) for > interactive web applications. The alternative to CGI is not "Java" or "C++" > or any other programming language. In fact, you can write a CGI application > in Java just as you would write one in Perl. > > The alternative to CGI is another API -- typically the proprietary API built > into whatever web server you're using. Microsoft's IIS server uses the > "ISAPI" and Netscape's iPlanet server uses "NSAPI". Both have similar > functions, but code written for one API is completely non-portable to the > other. > > The Java "Servlet" architecture is yet another API for web applications. > It, too, provides functions similar to web-server specific APIs. Servlets > are not inherently better. In fact, the Servlet API is less mature than > other APIs (it has not been around as long) and it is slower (it is build on > top of the web server's API -- thus unavoidably slower). Servlets promise > to be portable between web servers some day, but in practice different web > servers have slightly different Servlet API features. In contrast, the CGI > API is portable TODAY, and it is uniform across all web servers which > support CGI -- which is ALL of them. > > > Of course, once you've selected CGI, Apache, mod_perl and Perl as the > platform on which to build your web applications(!), be sure to use > CGI::Application! Remember that good or bad code can be written in any > language. CGI-App focuses on helping you write good code in Perl-based CGI > applications. Well said :) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
