Tobias Reif wrote: > Michael Neumann wrote: > > > I wrote: > >>1. > >>How would the complete FastCGI program look that can serve anything, > >>including Ruby programs that print their output? > >>Something that can fulfill requests such as > >>http://www.rubynewbies.com/~tobi/show_source.rb?file=show_source.rb&format=.xhtml > >>or > >>http://www.rubynewbies.com:9000/~tobi/show_source.rb?file=show_source.rb&format=.xhtml > > [...] > > > > The obligatory "Hello World" FastCGI application looks like: > > > > require "fcgi" > > > > FCGI.each_request do |f| > > $stdin = f.in > > puts "Content-type: text/html" > > puts > > puts "<html><body>Hello World</body></html>" > > end > > > Thanks so far; but I don't understand yet. Your examples, and the one on > the FastCGI page all serve one thing (one option). I guess I could get > those to run. Yes, one FastCGI application produces *one* dynamic page. But unlike a CGI app a FastCGI app gets it's informations (URL parameter, POST data) through a socket instead of stdin (variable f in the example above). And of course it will handle multiple request (it will stay in the FCGI.each_request loop). > No if I got that right, I would use FastCGI to prevent that a new Ruby > interpreter is started for each request to the server requesting a Ruby > program. > So if I got that right too, I would use a single FastCGI program > similiar to the three examples, with the main difference, that it can > serve any Ruby programs output. Then the one FastCGI program is always > running in one interpreter, and no additional interpreters are needed. > in pseudo code: > > ---all requests for Ruby programs go to that program--- > require "fcgi" > > FCGI.each_request do |f| > # get(find&open) and read the requested file > # if it's a Ruby program, check if allowed > # pass the params and eval it > # serve its' output > # else serve its' content. > end > -----------------------end--------------------------- > > This way, I don't need to have FastCGI code in each and every Ruby > program, but just one little FastCGI serverlein, that can handle any > request. > (perhaps this is feasible, by passing the files' name as param; but > perhaps it's not necessary.) > > Or did I get that wrong? that would work. > If I use something like the examples for each and every Ruby program in > my account, then wouldn't that result in a new intrpreter being started > for each Ruby program, like before? even worse, they would all stay in memory. But each Ruby program would only be started once. do you need that extra amount of performance given by FastCGI ? It makes only sense if the FastCGI scripts are called frequently. Otherwise just use CGI. > I'm sorry; I don't yet get the basic concept. > > Or does FastCGI handle that internally? I serve each and every Ruby > program using its' own little FastCGI servlet, and because FastCGI is > magic, only one interpreter is started, ever? That would be nice too. CGI works as follows: Suppose I invoke the page /cgi-bin/test.cgi, in which case the webserver executes the script named test.cgi (if it's a Ruby app, a Ruby interpreter is started). The data sent by the browser to the webserver is passed to the CGI application on stdin, while the CGI application outputs to stdout which is returned to the webserver and finally forwarded to the browser. Via the environment variables the CGI application can ask for the requested URL, server software, CGI version etc. Using FastCGI this is very similar with the difference that no application is invoked by the webserver as this is the case for a CGI script (unless you let it invoke automatically on request by mod_fastcgi; but this would happen once). You have to run the FastCGI application (e.g. by typing ruby myFastCGIapp.rb) before you can access the page generated by that FastCGI application in your browser. In the Apache conf you have to specify a host and port number on which your FastCGI application listens. Now if there is a request for your app the webserver sents the data forming the request through a socket to it. You see there is no magic. It's just a simple client/server application, where the FastCGI app is the server and the webserver the client. > I would intensely appreciate further enlightenment. > (anyone writing a book on serverside ruby?) > > Also: does FastCGI work well, generally? it is fast, scalable and works well for me. Regards, Michael -- Michael Neumann merlin.zwo InfoDesign GmbH http://www.merlin-zwo.de