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 _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/