When failings of Perl are enumerated as a reason not to use it, on top of the list you often find the dependency on mod_perl, and the fact that you run all the mod_perl as the same user and that all the mod_perl jobs running share the same memory space(or something like that). Of course, second is the fact that you don't use mod_perl and therefore have no state and run slowly.

In short, while mod_perl is handy to have for binding to Apache, it is also a liability inasmuch as that it can bring down an entire website if something goes Very Wrong. And not using it is often the Kiss Of Death.

I have never used fast_cgi, and therefore can not comment on it.

After Perl's problems with mod_perl, the next attack on perl applications is the use of the cgi interface. As a matter of fact, the demo site above was designed to client specification that the url be path based and not cgi-like. I mean, it's so polarized that lots of us end up faking it by using Apache's mod_rewrite ore equivalent.

There's no denying the weaknesses of building your own server from the ground up, and I am sure many people see it as blasphemy, given Apache's excellent capabilities.

However, I have found that Apache and Perl don't support my needs for bidirectional interaction such as n-user games through the browser using SVG due to the overhead Apache imposes on the whole process. I do much better keeping everything in the base thread's context, minimizing IPC comms and DB interaction. It allows me to have player 1 see the actions of player 2 without relying on an update and 2 selects on a database, which kills performance (I typically need better than 1 connection per second per player for n-user arcade-type scenarios)

With HTTP::Daemon, and Net::SSLeasy you can generate nice solid connections, maintain state very tightly with a minimum of third-party help from Apache, and keep everything tightly connected within a single instance. The performance is much higher than anything I've achieved with mod_perl and a database.

And I have found that web applications are very specific in their IO and functionality requirements and very much like the idea of a stand-alone system that does not require anything other than itself to run. Simply in matters of reduced dependencies and simplified configuration, this is a huge work saver for me.

IMHO, Maybe it is time to take a look at the important features of Java (such as the servlet) and take a lesson from them.

And it was really not much effort. Implementing the threaded listener takes about 75 lines. The security manips take about 50 lines, and the application data take about 400 lines total. I'll pay 125 lines in headache (especially if it is always the same) to get rid of the 99% of Apache I don't need. And if I want a proxy to handle the port 80 connection then I just have to put in a handler for it. So far I think it's a good model that I can't touch with mod_perl. Althoough maybe I need to take another at fast_cgi.

Hackmare