Ok, let's put it in a more mildly: Is cgi (common gateway interface) legacy?
yes? no?
Under what circumstances would a project starting today (one that does noot have to interact with legacy systems or libraries) use cgi?
+1
A:
CGI is not very well suited for high performance.
But my advice is to ignore that, write for a language or library that supports multiple SAPIs, and then use what fits best for each situation.
gnud
2009-09-23 08:16:56
CGI isn't that good for performance.
Clement Herreman
2009-09-23 08:26:00
CGI (not fast CGI) generally not good for performance because there will be no optimization for web serving (as they are likely to be written by language that is designed by web). However, if your CGI is computation intensive with little interaction (less Web serving but more computing), CGI written by compiled-to-native language will definitely out perform. That is why I use the word "computational performance". But then again, this kind of tasks is rare.
NawaMan
2009-09-23 08:50:07
+1
A:
It is not quite dead. But fcgi looks like much better approach. Though not officially supported by, say, Apache. You need to use side mods to get it to work.
FractalizeR
2009-09-23 08:27:24
+3
A:
Legacy? Absolutely. Dead? Well, it's on life support. I doubt it will really "die" in the forseeable future. You might still use CGI to write a very small sort of script if you've got a server with no other means of running a webapp and you're too lazy to configure it up.
What's another reason? Maybe you've got a program that leaks memory or resources like a sieve but you need to run it anyway, so you make sure everything is cleaned up by ending the process every single request...
But seriously, for things that really matter, I think the benefits of moving to any sort of system with persistent processes outweigh the costs by quite a bit. And in my experience, it encourages writing better-organized code as well, because the kind of initialization you need to have a nicely modular application translates to "unacceptable startup time" in a CGI environment.
hobbs
2009-09-23 08:27:36
+5
A:
It's far from dead actually. Despite the overheads, many virtual web hosting companies are now running PHP as CGI for security considerations, because it can be used with suEXEC. suEXEC means that your scripts execute under your actual Unix user privileges, and thus are restricted by the operating system's privilege separation. This is a much more robust security model than the PHP-specific open_basedir alternative.
Also, CGI is a really simple and quite versatile interface, support for it is never going out from web servers. Many newer interfaces like FastCGI and SCGI inherit the way that CGI passes HTTP headers and other variables to the web application and back. Even PHP's SAPI mimics this with its $_SERVER variable. So CGI is not going away, it is just being built upon.
intgr
2009-09-23 09:32:30
It's equally possible to run FastCGI through suexec, or through a process manager that's completely external to the webserver, and PHP's support for FastCGI is built in. But I wouldn't look at what shared hosting does as an indicator of the future anway. :)
hobbs
2009-09-23 19:30:12