Re: Re: Re: Ignorant Article

[hardburn]

The problem is not (ultimately) CGIs. It's HTTP. Any technology built on HTTP is going to run into the same issues. You're going to have to use some sort of kludge to get any sort of stateful information over HTTP, be it hidden input forms or cookies or whatever else. Asethetically, these are all awful solutions.

Replacing HTTP as an application platform would be wonderful. J2EE doesn't do that, and we shouldn't pretend that the handwaving it does is any less kludgy than solutions CGIs use.

----
Reinvent a rounder wheel.

Note: All code is untested, unless otherwise stated

[Anonymous Monk]

Your point is quite right I think. There are certain weaknesses built into HTTP that makes session management more difficult, though I don't know if I would consider all solutions kludges.

From an enterprise developers point of view, so long as you wrap a kludge in a strong enough component with a cler enough public API, then that is fine.

CGI.pm does a wonderful job at this and I am proud to say that Lincoln took comments from Gunther and me, while we were at the NIH Genome Project, when designing it.

That said, I equally enjoy working with Servlet Containers.

In the end, once objectified, so long as the kludge works, provided it is a black box to me and works, as a developer, then I am more or less satisfied.

I don't know if I would geive up HTTP though. I may just be old fashioned, but I rather like it as a standard.

- Selena Sol