From: Robert Wagner <rw@...>
Date: 2003-03-26T00:09:30+09:00
Subject: Re: acgi - a fastcgi alternative?

At 22:45 25.03.03 +0900, you wrote:
>On Tue, Mar 25, 2003 at 08:00:49AM +0900, ahoward wrote:
> > > 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'm not sure why it hasn't taken off so much. Many CGI application writers
>use PHP, and PHP support is noticeably missing from www.fastcgi.com, so they
>are forced to use mod_php. Perlers will likely use mod_perl if their
>webserver has it compiled in already, which is often the case (more than
>mod_fastcgi anyway)

what's wrong with mod_php? i think concerning simplicity, mod_php is the 
benchmark...
many users can update their scripts without having trouble with others, not 
needing
webserver restarts etc.

i once read, mod_php works with aggressive cleaning methods to achieve 
this. on the
other hand it's still quite fast. since ruby interpreter is so flexible 
(morphable) by the
hands of the user, how can one be safe,
that the next request will be answered by the same (regarding the premises) 
interpreter?


> From my point of view, FastCGI is the simpler alternative. One Apache module
>lets me run persistent C programs (e.g. sqwebmail), Ruby programs and Perl
>programs. Furthermore I get better visibility, since each application runs
>as a separate process, and therefore I can see it in 'top', attach a ktrace
>to it, etc.

>Also, an application can be restarted automatically if its source file has
>changed (although not the libraries it depends on):
>
>   FastCgiConfig -autoUpdate

what is a library? anything stated in "require"?

regards,
         robert