Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Hacking fun 10 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Won't you end up with something pretty similar to lighttpd + FastCGI?
    • Not really.

      Say you want to build an app - you don't want to fuss about deployment just yet. With this you can just download it, and run "./axkit" and start building your app. No downloading extra httpds and configuring them.

      When you want to deploy, you can either deploy standalone like this without an extra httpd, or you can stick lighttpd or apache up front, giving you whatever extra features you might need from those (e.g. SSL).

      All this is easier to debug than FastCGI, and can utilise proxy caching at the
      • I have read the original article and I think he's full of it. FastCGI's protocol is too hard to understand, so let's write an HTTP server? It doesn't make any sense. Writing a good network server is much harder than figuring out how to debug FastCGI hiccups.

        It sounds to me like you're solving a different problem -- how to have a quick dev server. Most projects are doing this with HTTP::Server::Simple. I personally think it's a bad idea to develop on a server that isn't identical to what you deploy on,

        • Why is it appreciably harder to write a good dæmon vs. a FastCGI frontend? That doesn’t make any sense to me.

          • Have you ever tried to write a reliable HTTP server that deals well with all the things that can happen with networks and broken clients, and has very high performance? There's a reason why apache httpd took more than a few hours to write. Now compare that to simply adding a little debug code to an already working FastCGI implementation.

            • So what you’re objecting to is not any of the stated goals, but just the fact that it would require effort that cannot build on something existing?

              • Re:lighttpd? (Score:1)

                by perrin (4270) on 2006.07.31 16:58 (#49122) Journal
                The stated goal that I saw in that article was "fix my (unspecified) FastCGI problems" and the solution was to write an HTTP server. It didn't make sense to me, and it still doesn't. Matt's goals (quick bundled dev server with decent production capabilities) don't seem related to what the article was talking about.

                In the article, Davidson complains about "zombies, mysterious crashes, and other annoyances" -- sort of like the kind you see when you try to write a new networkd server. He complains that you have to care about which release of the server software you're running. Well, duh. That applies to databases, OS, and everything else. He complains that you have to run a web server in front of your app. Making the web server run in the same process doesn't seem like an improvement to me.

                The way things are looking these days, serving static content from a single-threaded server and passing requests for dynamic stuff off to a separate daemon seems like the best formula anyone has come up with for scaling. It also happens to be what lighttpd + FastCGI already do. Maybe someone will build a better version of the same thing, but I don't see anyone building anything fundamentally different, and the FastCGI protocol itself is pretty obviously not the reason for anyone's problems, although the implementation might be.

                In short, I think the whole article sounds like a case of Not Invented Here. Having a non-HTTP protocol doesn't seem to have killed database servers, so why is it such a problem for FastCGI? It's not.
                • You haven't answered the point about frontend caching when sending the right headers. That can be a big win. Honestly the FastCGI protocol seems to be a solution in search of a problem - the HTTP protocol is perfectly suited to whatever the inventors were trying to achieve.
                  • Apache's mod_cache can cache any URL, so I assume FastCGI would be fine. I don't think lighttpd has caching built in, or proxying for that matter.

                    FastCGI doesn't seem very useful to me either, since I already have mod_perl (and many other perl options for that matter), but some of the people who I talked to at OSCON seemed to prefer FastCGI for its simplicity when compared to running another separate httpd daemon.

                    The bottom line for me is that it seems like a strange choice for Ruby. They don't have a mod

                • I don’t see how database server binary protocols are in any way a relevant example. They are closed proprietary wire formats, they have a single implementation for each end of the wire, and the code for both ends is written by the same entity. Noone expects the client library of MySQL to interoperate with the PostgreSQL server, yet people fully expect to be able to run the same FastCGI-fronted application under lighttpd, multiple different FastCGI implementations for Apache, and who knows what else.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.