From: ahoward <ahoward@...>
Date: 2003-03-25T08:00:49+09:00
Subject: Re: acgi - a fastcgi alternative?

On Tue, 25 Mar 2003, Brian Candler wrote:

> I don't see how this differs much from fastcgi, if you use the 'cgi-fcgi'
> program supplied with the fcgi library (it's a small C program which is
> invoked as a 'normal' CGI, which in turn passes on the request to one of a
> pool of FastCGI processes). That fixes the 'no external modules, no
> configuration of Apache' issue.

* session affinity
  - global data does not good without it (i'm aware of the patch btw., but
    it definitely ups complexity)
* simplicity
  - application reloads of pools are not fun.

> FastCGI is working very well for me, and I'll certainly persist with it -
> there's a lot of development already behind it, and the ability to run perl
> CGIs under the same API is extremely useful.

i agree with you.  however, my take is the benefits/complexity ratio is simply
not there for fastcgi and that this is why more people have not adopted it.  i
have been using it myself and really like it...

> I am just in the process of updating the ruby-fcgi module (programs now run
> either from the command-line, as normal CGI, or as FastCGI with no changes!)
> I'll post it tomorrow when I've finished working out why FreeBSD appears to
> be mangling signals...

i spent quite a few hours mucking with that too.  signals are evil IMHO and
should be steered clear of if simplicity and robustness are really desired.
i'm not saying it can't be done - just that it's one of those slipperly slopes
like threads and continuations.

i will definitely check out your patches to fcgi and give them a try.

-a



--
  ====================================
  | Ara Howard
  | NOAA Forecast Systems Laboratory
  | Information and Technology Services
  | Data Systems Group
  | R/FST 325 Broadway
  | Boulder, CO 80305-3328
  | Email: ahoward@fsl.noaa.gov
  | Phone:  303-497-7238
  | Fax:    303-497-7259
  ====================================