Hi Ara! We have crossing paths. Thanks for the tips on CGI_PARAMS.

I just took a look at scgi. It is easy to implement. However I question 
the wisdom of fork and pass fd's. That seems like a bad idea for 
portability. I can see scgi being useful in a server using threads or 
IO event model and keeping objects associated with requests. The server 
processes also need to be started by something outside of the 
web-server, so watch-dog and process spawning needs to be handled for 
start up.

If one server is used for all requests then a web client can be pinned 
to an object for session continuity. This may lead to performance 
issues and in the context of current Ruby threading that does not avail 
the process to multiple CPUs. I recently completed updating the Session 
Affinity patch for FastCGI, so I have my eye on this. Running multiple 
instances and distributing requests could work (with host names or 
cookies), but there is no initial round-robin arbiter.

FastCGI has the process start up and watch-dog functionality. The 
Session Affinity patch provides multiple instances, round robin 
distribution and session pinning.

I do not know if this helps.

Dan


On Tuesday, Mar 11, 2003, at 09:51 America/New_York, ahoward wrote:

>
>
> i am considering creating a ruby interface to this module :
>
>   http://www.mems-exchange.org/software/scgi/
>
> it's similar to fastscgi but is supposedly simpler to implement.  i 
> would
> interested if anyone has had any experience with it or enough 
> experience with
> fastcgi to make an educated comparison.
>
> -a