Re: Ignorant Article

[steves]

There's a lot of misinformation in that article. Sounds like it was written by someone who knows just enough to be dangerous. Let's look at a few pieces:

Maintaining state is possible with CGI using hidden variables, by encoding the URL, or by maintaining a state file on the server, it's just not easy or efficient.

There's that silly thing known as cookies that a few web sites use.

Second, every set of question/answers causes the web server to execute a unique instance of the CGI script. This is pretty expensive, especially on a high volume web site which may have 100 instances of a CGI script executing at any given moment, each, perhaps, with its own Perl interpreter.

How about mod_perl or fast CGI?

Finally, CGI scripts produce fairly ugly user-interfaces. Basically, CGI is limited to bland HTML-based forms and whatever bells and whistles can be provided by surrounding HTML layout. Thus, no CGI application looks like your swank bootleg copy of Word.

This may not seem like a big issue at first, but when you start competing for web hits with multi-million dollar companies, image is indeed everything. CGI simply cannot compare with web based applications which are not limited to HTML.

She's really confused here. Just what are those other companies using? Their own proprietary web protocols? Let's see, it could be JavaScript. I've had CGI's put that into generated pages ... Maybe style sheets? I've used those too. She gives no clue as to what this other magic is. The fact is a CGI script can put whatever it wants into a generated page.

The real miss here is that the entire web is basically CGI's. HTTP is a stateless protocol. Anything that appears to be something else is just putting wrappers around that stateless protocol to give it state and make it more usable. She appears to be picking on Perl CGI's in particular here (although she never really comes out and says that). What about other CGI programming languages? Are they any better? If so, why?

CGI's have their issues, but we can't just pack up the web and go home.

[Abigail-II]

Maintaining state is possible with CGI using hidden variables, by encoding the URL, or by maintaining a state file on the server, it's just not easy or efficient.

There's that silly thing known as cookies that a few web sites use.

Cookies are just another type of bandage, trying to patch the same wounds hidden variables and URL encoding are trying to patch. They are all attempts of hammering squares through round holes, creating "state" using a stateless protocol.

Second, every set of question/answers causes the web server to execute a unique instance of the CGI script. This is pretty expensive, especially on a high volume web site which may have 100 instances of a CGI script executing at any given moment, each, perhaps, with its own Perl interpreter.

How about mod_perl or fast CGI?

Yeah, what about them? Sure, you don't have to fire another instance of Perl. But you still need a three way handshake to create the TCP/IP connection (it usually takes longer to render a page and type in a response that it takes for the keep-alive timeout to expire), and the server still needs to do all the house keeping dealing with another request. And that's assuming there's just "a server". Enterprise systems often consist of many components.

She's really confused here. Just what are those other companies using?

Java, probably. I'm not at all a big fan of Java (but neither of CGI), but Java applets allow you to push a program to the client, deal with all the intermediate results *at the client*, and only make a connection again when there's an end result. Now, I realize that Java has its drawbacks too, but Java applets certainly fix some of CGI's problems.

Abigail

[steves]

These are all excellent points. I was hoping the author would have thrown things like this out for debate.

As for client heavy web sites, can you say boo.com?

A big part of our day is living within the reality that exists today. Stateless HTTP sucks in many ways. CGI sucks in many ways. Java applets suck in many ways. I can almost guarantee you that if they added state to HTTP tomorrow, we'd all be complaining about some aspect of it. Most -- heck, I'd say all -- of the technology I use has at least one dimension of suckiness. My problem with the article is that it mixes all the suckiness up into on cauldron then assigns a label that, at least in a veiled way, points to one of the ingredients. You get some pointy hairs reading that stuff and next thing you know they mandate "no Perl" or something similarly stupid.

At one job we outsourced GUI development and got a really bad result, even though from a checklist perspective everything was "okay." The problem was with the coding. Management banned the tool that was used from ever being used again. As if the tool, which actually seemed quite good, was responsible for the poor use of itself. That's the reality of our world. Who here can claim that if the author of N books spoke to your boss he wouldn't listen at least a little? I think it's our responsibility to keep writers, experts, and ourselves honest.

[selenasol]

Abigail, when my darn site finally comes upagain, you might want to checkout the JavaToCGIBridge bean that my CTO, Gunther wrote to allow you to easily integrate Applets to CGI.

That said, I am not personally a big fan of applets. I tend to think that dHTML does enough of what is required. But I have written my fair share of both types of GUIs.

[Abigail-II]

Thanks for the offer, but I don't think so. I really dislike to do any sorts of Web programming. Generating simpe HTML pages is ok, but anything interactive, big yuck. Whether that's in Perl or any other language.

Abigail

[tachyon]

The security concerns are valid to a degree

#!/usr/bin/perl
$|++;
use CGI qw( :standard );
use CGI::Carp qw( fatalsToBrowser );

print header(),start_form({ -method=>'get' }),
      textfield({-size=>75,-name=>'command'}), submit('Run'), end_form
+();

if (my $command = param('command')) {
  open( CMD, "$command 2>&1|" ) or die_nice( "$!: running command: '$c
+ommand'" );
  print "<pre>\n";
  print escapeHTML($_,1) while (<CMD>);
  print "</pre>\n", end_html;
  close CMD;
}

sub die_nice{ print shift and exit }

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

[John M. Dlugosz]

use strict, warnings, and taint checking. I think taint checking was ahead of its time when it came out, and vastly underused today. Other languages are just beginning to incorporate something along those lines.