[Catalyst] FastCGI is Weak Sauce

[Perrin Harkins]

A. Pagaltzis wrote:
> Yes. I take his argument as being that FastCGI has the
> application running in a separate process that can’t be
> communicated with in absence of a webserver because there aren’t
> any utilities that speak FastCGI directly, and if the connection
> between the webserver and the app process isn’t working, you’re
> basically S.O.L.

Sure, but you could make this argument about databases, or SSL, or 
anything else that isn't plain text.  There's no reason to abandon a 
tool that is working for you just because it uses a binary protocol. 
It's not like zombie processes and socket problems suddenly disappear 
when you start using a plain text protocol.

> Yes, that’s what I was wondering about – and I say “wondering”
> because even though Apache plus mod_perl plus custom app works
> the same, deployment is not exactly easy.

We try pretty hard to make mod_perl easy to compile.  There are good 
binaries for Windows.  If you have a specific issue, you're welcome to 
bring it to the mod_perl list.

> Basically, what JDD writes makes me think of SQLite.

SQLite is neat, but it's kind of slow and has poor concurrency, so it 
doesn't scale.  It's actually a useful analogy here, since it 
illustrates how hard it is to write an efficient, scalable system.

> Embedding the HTTP engine right into
> the app should likewise make it a whole lot easier to deploy and
> manage.

But if that's what you want, why write your own when you can take an 
incredibly solid HTTP server and embed Catalyst directly in it via mod_perl?

- Perrin