Slashdot Mirror
Web Programming by printf()
An anonymous reader writes "Art & Logic has posted an article titled 'Why CGI is Evil'. CGI might be an obvious way to create a simple web application, but this article provides some excellent high-level reasons why CGI rarely makes long-term sense. A nice review especially for new web programmers."
I think CGI also refers only to those programs that the server calls directly passing headers in a certain format. While the script may be written in any language, they tend to be written in a language that is primarily a programming language (Perl, C, Python, etc) rather than a content-oriented language (ASP, JSP, PHP, etc).
JSP usually runs as a separate server that may be contacted by the web server, but is also capable of answering web requests by itself. ASP and PHP are run in the same process space as the web server, and thus can spare the overhead of spawning a new script interpreter for every request. All of these languages are content-oriented, meaning that the scripting code is embedded in the document, rather than having the document embedded in the code.
Hopefully I haven't confused matters even more ;)
I can't say that I don't give a fuck. I've just run out of fuck to give.
Without much hassle, you can use XS to allow your Perl scripts to interface with C/C++ libraries in a natural way. In fact, many Perl modules are written in C/C++ and wrapped with XS. This allows you to get the best of both worlds in some situations -- streamlined C code to offload intensive operations into separate libraries, then rapidly prototypable Perl front ends to those libraries (whether it be mod_perl for web apps, Perl/GTK for GUI, or any other type of front end you need).
It's not always the perfect solution, but your post makes it seems as if you don't think there's any way to get C and Perl to talk. Few things are further from the truth. And this isn't just some nifty Perl thing -- many of the "scripting" languages (I can't speak for PHP) offer similar ways to accessing C/C++/etc. I'm just most familiar with Perl's way.
I think CGI also refers only to those programs that the server calls directly passing headers in a certain format.
/administration/). They're compiled and placed into the classpath, and then the server executes them in the JVM when a request is made. The benefit is that the code is precompiled and the JVM is preloaded, so the execution time once loaded is almost as fast as a CGI applet would be once loaded, but the load time is less because it doesn't have to fork a separate process.
CGI refers to the method of executing external programs, passing parameters to them as environment variables, and then getting the result back from standard output. CGI tends to be external binaries, and thus PHP can be essentially CGI if you use it in its CGI binary form (needlessly complex, and even worse of a performance hit, but it works).
JSP usually runs as a separate server that may be contacted by the web server, but is also capable of answering web requests by itself.
Most of the servers I've seen tend to glob everything together, so I'd be inclined to disagree with the 'usually' here. I've usually run it as the 'tomcat' process, which is its own thing.
You neglected to mention servlets, which are a nice cross between CGI and markup languages like ASP/JSP/PHP. Servlets are small Java programs that are mapped to a directory on the website (like
That's my imput for the day. If Aridhol hasn't confused matters enough, this hopefully will.
--Dan
CGI on the other hand defines how that information can be passed to external programs by the server (using environment variables and standard in), and how the external program passes information back to the server to be sent to the browser (via standard out).
A full specification is available from NCSA
CGI is pretty much the oldest method of a web server interacting with outside code, and is kind of the only standard way. The server fork/exec's a process and has the CGI process' stdin, stdout, and stderr are pointing back to the server. The web server passes information either through environment variables (for a GET request) or additionally through the process' stdin (for POST and PUT requests).
Advantages: very clean, the process goes away after the request, so resource leaks aren't a problem. Very simple interaction, if your programming language understands stdin, stdout, and environment variables (hard to find one that doesn't) you can do CGI with it (though some are better than others obviously).
Disadvantages: fork/exec for every request. That has some overhead, sometimes more important is that the process can't use persistent state. Resources have to be acquired on every request. Anything with a great deal of overhead, say opening a database connection, has a HUGE impact on the server.
FastCGI is a pseudo-standard in that it has multiple people implementing it, but it never got approved by, say, the IETF. It's a client server kind of thing, where the first instantiation starts the server up and initializes it. Subsequent requests get sent to the CGI server and get returned. The CGI server never goes away. The cool thing is that there are no startup costs, and you can keep something like a DB pool. Never really used it, so can't comment much.
Some things just get embedded into the server, like Apache modules. You can write C code and it becomes part of the server itself.
Advantages: wicked fast. Full access to anything in the server.
Disadvantages: if your CGI has a problem, it can bring down your server. The API's can be pretty arcane. Also, it's a different API for each web server (NSAPI vs. ISAPI vs....) and even between variants (it's wildly different from Apache 1.3 and apache 2.0).
mod_perl is kind of like above, it's a perl interpreter bound into Apache. Gives a perl interface to pretty much everything apache has to offer. Not only requests, but configurations.
Advantages: perl is very flexible, can do a lot of things and use perl modules from CPAN, including templating systems and the such. You're also insulated a bit from stray pointers and such. mod_perl also precompiles all of the perl code, so you don't have the compiler overhead on every request.
Disadvantages: mod_perl can be huge sometimes, and if you have several mod_perl instances running around, you can eat memory pretty quick.
Everything else is kind of "do what you want". Tomcat itself has several protocols to talk to Apache; some are just old, some are supported on certain platforms only, yadda yadda.
That said, the article did confuse a bunch of things, CGI, C, and content management systems. He was pushing an agenda, hopoing that people couldn't see through it.
When you consider that all (or most) web servers in the embedded systems market are currently using CGI, the author's article is quite brilliant. Remember, the embedded systems world is about 5 years behind the traditional "web development" world. The embedded guys are using many of the same technologies but for completely different purposes. For example, it looks like Art & Logic is also using XML-RPC and SOAP, but in a completely different context than most of us are used to.
Servlets and .JSPs become the same thing behind the scenes, but they are conceptually two different things.
.JSP view components and JavaBean model components. Typical use is one or a few controller servlets, which receive requests from .JSP forms and invoke logical operations in JavaBeans or Enterprise Java Beans. You want to avoid putting VERY much logic into the servlets, instead deferring processing to the business object layer.
(The following assumes that developers are using a reasonable architecture, rather than ad-hoc throwing together of technologies)
To take an MVC view of this, servlets are primarily used for the controller portion of an application. As straight Java code written to a specific interface, they provide a natural linking point between
A framework like Struts enforces this by providing you with a pre-packaged controller servlet, which you extend with a combination of classes that are servlet-like and XML to bind 'em all together.
It was a joke! When you give me that look it was a joke.