[Sputnik-list] FastCGI

[Yuri Takhteyev]

(Replying to the list, hope you don't mind.)

> Any ideas on how much would need to change in order to use FastCGI
>  instead of CGI?  I'd love to get a chance to test things out over the
>  next few days.  If you can nudge me in the right direction, I'll do
>  what I can to test things out.

I tried it yesterday and had trouble making WSAPI run with FastCGI.  I
don't think it's a Sputnik-specific problem, however.  If you get
CGILua or WSAPI to run with FastCGI, then you should be able to then
run Sputnik with it.  The best thing to do here I think is ask on the
kepler list on how to run WSAPI applications with FastCGI.  Fábio said
it can be done, so we should take him up on this. :)

My plan generally is to migrate to WSAPI.  I put the CGILua adapter
back because I realized that WSAPI doesn't work with Xavante in the
latest release and that people wanted to run Sputnik on Xavante.  I'll
probably keep the CGILua adapter there in case someone wants to use
it.  But really the long term plan is to run Sputnik as a WSAPI app,
so that I could forward any questions about FastCGI etc. to Fábio!

That said, in the longer term Sputnik's code might benefit from
rethinking to take more advantage of FastCGI.  Right now FastCGI will
save you on having to start a new process every time, but the
"sputnik" object will be recreated and lost for every request, and all
the necessary nodes (_config, _templates, etc.) will be read from disk
again.  Eventually I want to fix them, so that subsequent requests
would reuse the same "sputnik" object.  To do this I would have to
figure out how to keep track of what nodes become "dirty," however,
which will take some thought in the situation when multiple FastCGI
threads are handling requests.

  - yuri