Re: [Catalyst] FastCGI is Weak Sauce
A. Pagaltzis wrote: Hi all, this was written about Rails apps, but all the conceptual points are 100% applicable to Catalyst: The Web Is a Pipe http://duncandavidson.com/essay/2006/06/webaspipe I’m not as sure about the practical points. In particular, I have no idea what Mongrel really does, although I heard about it before and wondered if it’s something the CPAN needs and could steal. I’m also unsure about how the existence and deployment of mod_perl affects these issues. But I know he is dead on the money about pipes. So whatever the conclusions where Perl and Catalyst are concerned, this is worth thinking about. Talking a well-defined binary protocol down a pipe is also not hard. I don't really see what the fuss is about. -- Matt S Trout Offering custom development, consultancy and support Technical Directorcontracts for Catalyst, DBIx::Class and BAST. Contact Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ + ___ 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/
Re: [Catalyst] FastCGI is Weak Sauce
So we should just run the myapp_server.pl script instead of FCGI. It speaks HTTP!! Joking... only joking... On 6/29/06, Matt S Trout [EMAIL PROTECTED] wrote: A. Pagaltzis wrote: Hi all, this was written about Rails apps, but all the conceptual points are 100% applicable to Catalyst: The Web Is a Pipe http://duncandavidson.com/essay/2006/06/webaspipe I'm not as sure about the practical points. In particular, I have no idea what Mongrel really does, although I heard about it before and wondered if it's something the CPAN needs and could steal. I'm also unsure about how the existence and deployment of mod_perl affects these issues. But I know he is dead on the money about pipes. So whatever the conclusions where Perl and Catalyst are concerned, this is worth thinking about. Talking a well-defined binary protocol down a pipe is also not hard. I don't really see what the fuss is about. -- Matt S Trout Offering custom development, consultancy and support Technical Directorcontracts for Catalyst, DBIx::Class and BAST. Contact Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ + ___ 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/ ___ 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/
Re: [Catalyst] FastCGI is Weak Sauce
* Perrin Harkins [EMAIL PROTECTED] [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/ ___ 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/
Re: [Catalyst] FastCGI is Weak Sauce
A. Pagaltzis wrote: * Perrin Harkins [EMAIL PROTECTED] [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. Sure, but my immediate thought is so write the tools. Shouldn't be that hard to pull apart something like FCGI.pm and build a diagnostics tool from it. 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? On my would be nice to have list is a POE webserver/static file server/fcgi handler that we could bundle to do moderately scalable pure-perl deployment. And I've happily used the standalone server in forking mode to handle lightweight deployment; just because it's usually referred to as the development server doesn't mean that's all it's good for. So, Catalyst has both options available, although if you know what you're doing a real webserver plus fastcgi will perform better than the standalone server ever could. Other than we need to write better tools for fastcgi debugging, but I'd rather re-invent the wheel instead I can't see what of this article isn't merely stating the obvious - and suggesting things Catalyst already happily supports ... -- Matt S Trout Offering custom development, consultancy and support Technical Directorcontracts for Catalyst, DBIx::Class and BAST. Contact Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ + ___ 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/
Re: [Catalyst] FastCGI is Weak Sauce
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/
