> I said public target.
You are technically correct, the best kind of correct.
> I didn't say CGI just stopped existing and emphasized commercial use - it was too slow too once you hit even relatively medium-ish traffic.
And I agreed by stating:
> And, of course, FastCGI[2] is a welcomed optimization and to be preferred, but fundamentally is just that. An implementation optimization of CGI.
For efforts which do not need to scale, "classic CGI" can be a good fit. FastCGI can help increase the scale ceiling. Proprietary extensions can further do so.
Now the industry finds itself rediscovering CGI in the form of AWS Lambda[0] and Azure Functions[1], albeit addressing traffic concerns via "the cloud."
Funny how what was old is now new, eh?
0 - https://docs.aws.amazon.com/lambda/latest/dg/welcome.html
1 - https://docs.microsoft.com/en-us/azure/azure-functions/funct...
Hah, no, I was the regular kind of correct, you just misread what i wrote - the best kind of read.
As to the other thing, I wasn't arguing about the merits of CGI just that the commenter's recollection was a few years off. A lot of stuff happened in that '94ish-'98ish period as the web went commercial.
Whether lambda is a forgotten CGI, it's a different tangent but I'm not sure I agree. The share-nothing architecture is still (give or take) the norm in HTTP request handling. CGI's attractive feature was implementation-language independence. Lamda's attractive feature is scaling independent of some big unwieldy discrete compute unit (hence 'server-less', you don't scale in servers).
I said public target. The thing was aimed at web pages, the sell was applets.
Not quite true either.
I didn't say CGI just stopped existing and emphasized commercial use - it was too slow too once you hit even relatively medium-ish traffic. FCGI, NSAPI, in-process-tcl, plopping-piles-of-C-in-your-own-custom-apache-build were all solutions to that problem.