Pythonic way of web-programming

[Jon Ribbens]

In article <0gqdnfw_XuYm3gCjXTWcow at speakeasy.net>, A.M. Kuchling wrote:
>> I don't think FastCGI has much relation to CGI.  I don't entirely
>> understand FastCGI, but from what I can tell it just sucks -- it's
>> easier to do the same thing with a simpler socket connection ...

You're wrong - FastCGI is excellent. It's a reasonably simple,
standard, well-supported, platform-independent way of speeding up your
CGI scripts. It provides nearly all the advantages (and in some ways,
more advantages) of something like mod_python without any of the
disadvantages of having to run your scripts in the same process as the
web server.

> The FastCGI protocol is really complicated because it supports multiplexing 
> several different transactions over one socket.  Data is broken up into
> multiple packets, each with a unique transaction ID, and the process on the
> other end can then reassemble them and hand them out to different threads.
> However, I'm not sure the Apache mod_fastcgi supports this and few client
> modules seem to, so all of that complexity buys nothing in most cases.

You are correct in that mod_fastcgi does not support this
multiplexing. I am not aware of any clients that do support it either,
except the one I wrote (jonpy) ;-). I don't agree that FastCGI is
particularly complex though, and even if you think it is it makes no
difference if you simply use a ready-made library to take care of all
the FastCGI work for you.