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.

AxKit2 Status: Fastest perl httpd? 17 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Surely the best way to get not just Catalyst and Jifty but a lot of other Apache-based Perl applications is to allow them to drop in their Apache configs unchanged. In the basic case of a PerlModule being the only thing sitting on a virtual host, this shouldn't be too difficult to do, right? It ought to be just a matter of parsing the config file, and providing an Apache::Fake object to them.
    • Yes, there's a possibility of doing something a bit like that. Though I don't want to get people's hopes up that the Apache API will be fully implemented as some of it simply won't fit (I don't think).

      This is also basically how the SAWA plugin works - it fakes up an Apache::Request-a-like and passes it in.
  • Hi, interesting stuff. I assume you are also using Danga::Socket.

    Where can we look at the code? Sorry if I missed a previous post with the link, but I didn't get it.

    I ask because I also want to make this work with Catalyst.
    --
    life is short
  • Any ideas how to handle database access from this? Something like what POE does? Send the requests off to a separate PPerl/mod_perl?
    • Potentially. I'm not totally set on how to handle DB queries yet - my guess is that with sufficient caching in place it won't matter (and for the places building solutions where they don't care to cache, it probably doesn't matter anyway).

      But yes, likely some sort of separate process we can marshal requests to/from. I'd like to make it as transparent as possible, so what I might do is implement a DBD driver that does this natively.
      • How about things that are not I/O-bound but just compute intensive? Will you do some kind of cooperative time-slicing system similar to what POE does?
        • For that I am writing a class that forks off and sends the response back when ready. If compute intensive is very common I suggest just using a CGI (which we support already).
          • If you could have whatever it is able to support working with the Process.pm API, that would be nice.
  • Am I right in thinking that if you could abstract out the XML stuff (or just make it optional in the plugins—maybe it is already?) that the only requirement for the axkit2 Web server would be Danga::Socket? That's pretty rockin'!

    —Theory
    • Yes. The xmlresponse is already mostly optional. It loads it, and so loads XML::LibXML, but you don't have to implement that phase. I'm sure I could figure out a way to make it entirely optional (or even load XML::LibXML at runtime).

      Of course why you would want a web server without XML::LibXML installed is beyond me ;-)
      • That would rock. I was thinking about using it with Bricolage, for example, where we don't do anything with XML.

        My thought is that it'd be cool if it was a Web server that supports plugins and nothing but a Web server that supports plugins.

        Oh, another q: Would it be possible to allow plugins to be CPAN modules, and then we can just tell the Web server to use a CPAN module as the plugin for a particular Location.

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