modperlite

I just got this wonderful email from Aaron Stone:

Check out my github repo, I just tagged version 0.10 and it works and runs Movable Type! I can't take credit, mattn@github figured out which Apache calls would actually allow POST to work.

This is amazing and oh-so-excellent. Time to start testing. Major props to sodabew and mattn!

For those following this project, mod_perlite is looking for help from developers to pick up the ball and get this thing moving again. Aaron has done a great job to-date getting a basic prototype functioning, but a lot more work is needed if this could possibly serve as a replacement to mod_cgi.

I asked Aaron to compile a "to do" list to help communicate to developers more concretely what we need help with. Here is the latest from github:

• Fix form POST processing ('read' does not work reliably)
• Limit Perl running time.
• Find ways to cache code.

And some ideas of my own:

• It would be great if there was a way to configure what Perl modules should be loaded into memory and shared across requests. Given that mod_perlite is stateless this will help reduce load time by effectively pre-loading much of what is needed by a CGI application.

• Unit Tests - 'nuff said.

• ./configure script - I "love" makefiles just as much as everyone else, but I would much prefer to use a more platform agnostic framework like the nearly ubiquitous configure script.

The last check in was in December so I am hoping we can pick up the ball on this again soon. What the project is in real need of is people with knowledge of the following:

• writing Apache modules in C.
• overriding system calls in Perl, or someone familiar with mod_perl internals.

If you or someone you know fits the bill encourage them to speak up - we need their help. *

A couple of weeks ago Aaron and I spoke with chromatic about one of the Five Features Perl 5 Needs Right Now. It was a long conversation and it took some time to create the transcript, but it is finally available. Thanks chromatic!

A mailing list has been setup on Google Groups to help facilitate the discussion and community of users interested in helping to develop mod_perlite. Join now:

• http://groups.google.com/group/modperlite

chromatic published earlier today on OReilly's blog network an article entitled, Five Features Perl 5 Needs Now. In that article he identifies mod_perlite as a critical missing piece to the Perl 5 stack:

mod_perlite, the equivalent of mod_php for Perl. mod_perl is an amazing piece of technology, but it asks a lot of administrators -- it effectively takes over the web server. Perl on the web could benefit from a system which allows cheap hosting providers to say "Just upload a few files into this directory, and everything will happen for you automatically!" without worrying about other customers on the same host fighting for resources (or namespaces or memory or...).

Very Serious Developers may still use mod_perl -- but novices and the rest of us who aren't handling more than a hit per second at peak time should have something easier to set up and gentler on resources than CGI.

Naturally, I couldn't agree more. Now is the time for those developers with the knowledge, ability and desire to help, to step up. I firmly believe this is easily within our grasp. We just need the will to do it!

Simply put: CGI is too arcane and doesn't scale, and mod_perl is overly complex and presents too many challenges to hosting providers. One reason PHP has succeeded so wildly is that is was a programming environment designed for the web. As such, it sought to keep the benefits of CGI:

• immediate gratification - you don't need to compile PHP which means you can code and refresh and see your changes instantly. For designers as well as developers this is essential and very gratifying.
• simplicity - its built right into the web server, you don't need to host a separate server and proxy requests to it. It just does it natively.
• stateless - you don't have to worry about memory leaks. Each request is its own and won't overtime, become a problem for other services running on the machine.

While also solving a principal challenge with CGI:

• performance - CGI requires a perl interpreter to be launched and initialized with every request. Not a big deal for small sites, but for big ones? Yowzers.

And avoiding the pitfalls of the over engineered mod_perl:

• installation - if you have ever tried to install mod_perl then you know what I mean. It is huge. It is powerful. And it does a whole lot more than you need in a lot of cases.
• supportability - mod_perl is a complicated beast and as a result most hosting providers do not make it available to customers because it costs them too much to support.

This project seeks to build the next generation Perl container for web servers that is: easy to install, fun to use and imminently supportable.

Additional Resources and Articles

• How to fix CGI
• Is PHP falling out of favor with hosting providers?
• mod_perlite working!

The modperlite project started at Six Apart, but in an effort to encourage a broader community to help contribute and help out, the source code has been moved to github.

• http://github.com/SodaBrew/mod_perlite/tree/master

A TODO list is being assembled by Aaron to help other developers know what help is needed.