December 2008 Archives

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:

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!

Why mod_perlite?

| No Comments | No TrackBacks

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 get the source

| No Comments | No TrackBacks

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.

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

About this Archive

This page is an archive of entries from December 2008 listed from newest to oldest.

January 2009 is the next archive.

Find recent content on the main index or look in the archives to find all content.


Powered by Movable Type 4.23-en