4 ms·

> > Back when the web was young (before 1998 or so), webpages were generally static HTML files that you dumped in a directory and the webserver served up verbat

> > Back when the web was young (before 1998 or so), webpages were generally static HTML files that you dumped in a directory and the webserver served up verbatim. > You should probably be feeling a bit older (and perhaps forgetful :). Perhaps we all should :). > PHP was around in the mid 90s ... True, and according to the PHP site[0]: PHP as it's known today is actually the successor to a product named PHP/FI. Created in 1994 by Rasmus Lerdorf, the very first incarnation of PHP was a simple set of Common Gateway Interface (CGI) binaries written in the C programming language. > ... Java's initial public target was web pages. Not true, according to here[1]: In 1991, a small group of Sun engineers called the "Green Team" believed that the next wave in computing was the union of digital consumer devices and computers. Led by James Gosling, the team worked around the clock and created the programming language that would revolutionize our world – Java. The Green Team demonstrated their new language with an interactive, handheld home-entertainment controller that was originally targeted at the digital cable television industry. > CGI lived a long happy life in shared hosting, small project and development environments but in commercial use, it didn't last very long - it was just too slow. Not quite true either. Unless one considers the following projects no longer in use: - https://httpd.apache.org/docs/2.4/howto/cgi.html https://httpd.apache.org/docs/2.4/howto/cgi.html - https://docs.microsoft.com/en-us/iis/configuration https://docs.microsoft.com/en-us/iis/configuration /system.webserver/cgi - https://docs.python.org/3.4/howto/webservers.html https://docs.python.org/3.4/howto/webservers.html - http://www.yolinux.com/TUTORIALS/BashShellCgi.html http://www.yolinux.com/TUTORIALS/BashShellCgi.html And, of course, FastCGI[2] is a welcomed optimization and to be preferred, but fundamentally is just that. An implementation optimization of CGI. 0 - https://www.php.net/manual/en/history.php.php https://www.php.net/manual/en/history.php.php 1 - https://www.oracle.com/technetwork/java/javase/overview/javahistory-index-198355.html https://www.oracle.com/technetwork/java/javase/overview/java... 2 - https://en.wikipedia.org/wiki/FastCGI https://en.wikipedia.org/wiki/FastCGI

pvg 7y ago
Not true, according to here 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.
- AdieuToLogic 7y ago
  > > Not true, according to here > 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 https://docs.aws.amazon.com/lambda/latest/dg/welcome.html 1 - https://docs.microsoft.com/en-us/azure/azure-functions/functions-overview https://docs.microsoft.com/en-us/azure/azure-functions/funct...
  - pvg 7y ago
    You are technically correct, the best kind of correct. 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).

pvg 7y ago

Not true, according to here 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.

AdieuToLogic 7y ago
> > Not true, according to here > 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 https://docs.aws.amazon.com/lambda/latest/dg/welcome.html 1 - https://docs.microsoft.com/en-us/azure/azure-functions/functions-overview https://docs.microsoft.com/en-us/azure/azure-functions/funct...
- pvg 7y ago
  You are technically correct, the best kind of correct. 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).