At 02:21 AM 9/7/00 -0400, Dan Green wrote:
>I was poking around the FastCGI site, and tucked away in the FastCGI DevKit is
>a CGI to FastCGI bridge. Basically, it's a regular CGI capable of connecting
>to a FastCGI server and all that, but without having to store its state in
>memory (as a webserver module). Given that this exists, why are we maintaining
>adaptors at all? Why not drop them and just use FastCGI all the way, since
>duplicating effort is always lame? It seems to me that the FastCGI project has
>its head screwed on right, and that by maintaing our own (Python-specific,
>mind you!) adaptor setup, we're just wasting development time that could be
>poured into making Webware better.
>
>I'll even do the conversion myself ... I was going to anyway, since the
>sysadmin that I'm working with doesn't really see the need to have more than
>one process running on the box to do the same thing. I find myself agreeing
>with him. The Apache -> FastCGI -> Webware setup does seem strange, IMHO.
>
>Just throwing it out there. It would solve the discussion Chuck and I were
>having about how the adaptors should work in the future ... it'd just all be
>FastCGI!
Wouldn't a mod_python adapter that was resident in Apache and talked
directly to the app server be faster than launching a CGI on every request
that talks to the FastCGI adapter that talks to the app server?
I don't have anything against your idea of using this bridge; I think it's
good, but I also think it's likely that we'll have more than one adapter in
order to squeeze more speed from the situation...
-Chuck
|