[Catalyst] FastCGI is Weak Sauce

A. Pagaltzis pagaltzis at gmx.de
Fri Jun 30 02:40:05 CEST 2006


* Perrin Harkins <perrin at elem.com> [2006-06-29 23:20]:
> If I'm reading it correctly, he's upset that the protocol
> between web servers and FastCGI isn't HTTP. He doesn't make a
> very good case for why, but that seems to be the gist.

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. because the app and webserver FCGI components
don’t give you much information and diagnosing the problem
without any tools is difficult at best.

I think that much is just fact.

> He wants to run Rails directly in a web server instead. His
> solution is to write an HTTP server in Ruby to stick onto the
> front of Rails (that's what Mongrel is), which also doesn't
> make much sense, given how hard it is to write a truly bug-free
> HTTP server. (Probably a lot harder than it was to write
> Rails.)

Sure, but it isn’t blue-sky musing. Mongrel already exists and is
purportedly extremely solid code. So that’s not an open concern.

> Silly complaint or not, people running mod_perl already have
> this covered, since the normal mode of deployment is to run a
> static web server and proxy via HTTP over to a mod_perl server
> for all dynamic stuff, i.e. exactly what he's trying to build
> for Ruby.

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. (It might be easy for
you – I know who you are –, but I don’t have your experience and
I know it’s not easy for me.) Meanwhile Catalyst doesn’t really
take advantage of mod_perl anyway.

Basically, what JDD writes makes me think of SQLite. Embedding
the database engine right into the app makes it tremendously
easier to deploy and manage. Embedding the HTTP engine right into
the app should likewise make it a whole lot easier to deploy and
manage. Sure, writing a solid embedded HTTP engine is no mean
feat, but writing a solid embedded database engine isn’t either,
and both have been done.

It all seems awfully obvious to me; am I wrong?

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>



More information about the Catalyst mailing list