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
