On 29 May 2002, Patrick K. O'Brien said:
> [Greg Ward]
> > CGI just sucks all around in so many ways.  I can't believe you used the
> > words "CGI" and "scale" in the same sentence without a negative.  ;-)
> > You should probably pester Neil to finish the CGI<->SCGI gateway -- that
> > sounds like a good compromise to me.
>
> What exactly will that gateway buy me? And what's going to be needed on the
> server side? Remember, I've got a hosted account that allows CGI, but not
> long running processes (in theory, at least, but I might be able to beg).
> Thanks.

If your server allows long-running processes but not (say) FastCGI or
mod_python, then I presume the CGI<->SCGI gateway would work like this:

  * browser makes request
  * HTTP server passes request to /cgi-bin/yourapp_gateway.cgi
  * this is a small, compiled C program that knows just enough
    to contact an SCGI server running somewhere (presumably
    some port on localhost) and translate the CGI request
    into an SCGI request
  * the SCGI server does all the heavy lifting and sends the
    request via the SCGI protocol to the small gateway program
  * the gateway program returns the result to the HTTP server
    via its stdout, which passes it to the browser using HTTP

This is not as good as having an SCGI client right in the HTTP server,
which is what Neil's mod_scgi is.  But it's *much* cheaper to fork a
small C program than to fork a Python interpreter that loads lots of
modules, opens database connections, etc.

If your hosting provider won't even allow a long-running SCGI daemon,
then you're stuck.  They key to decent performance in web applications
is long-running server processes; it doesn't much matter whether you use
FastCGI, SCGI, PersistentCGI, mod_{python,perl}, or what -- any one of
those will be orders of magnitude faster, and far less load on the
server, than plain old CGI.  Probably the "less load on the server"
argument is your best bet with your hosting provider.  (Or the old
standby: you can always take your business elsewhere!)

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org