Re: Ignorant Article

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

Comment on Re: Ignorant Article

Replies are listed 'Best First'.
Re: Re: Ignorant Article by steves (Curate) on Feb 19, 2003 at 00:18 UTC
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.	[reply]
Java and CGI by selenasol (Novice) on Feb 19, 2003 at 16:49 UTC
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.	[reply]
Re: Java and CGI by Abigail-II (Bishop) on Feb 19, 2003 at 19:44 UTC
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	[reply]