Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • There is talk of a second edition and some of what you brought up is likely to be covered.

    For now, I'm finishing up one book (Unix PowerTools)
    and then I'm taking a long walk off a short pier. :-)

    Thanks again.
    • They're doing a second edition to Unix Power Tools? That's cool. That's one of my favorite ORA books, even if I don't use it so much any more.

      On a slightly different tangent, one thing I'm beginning to notice about a lot of bundles is that they tend to roll their own servers that provide only very basic server functionality, and Frontier::Daemon falls into the same category (which I realize is a subclass of HTTP::Daemon).

      I'd really like to see some sort of ultra-flexible & robust super class that could be used by future authors instead of having to write some home-grown daemon. I think Net::Server has the most potential in that area, even though I've personally had problems with it. It's still a great idea, I think, as it allows you to select options like setsid (a must for any server IMHO), max forks, max threads, etc.

      Any opinions? Anyone?

      • Oops, I meant 3rd edition.
      • /me opens can of worms

        There are good reasons to use a standalone HTTP server. Look at Samba's SWAT utility, for instance. However, the Apache project is such a great platform for serving dynamic content, it seems foolish to try to to reimpliment it in Perl. So, my preference is to show people how to exploit Apache with XML-RPC (or SOAP) and leave the standalone HTTP servers for "vertical" applications.

        Once again, I'm beginning to thing about what I'd show in the 2nd ed. of XML-RPC and I now I'd talk abo