Recently in Documentation Category

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

About this Archive

This page is an archive of recent entries in the Documentation category.

Developers is the previous category.

News is the next category.

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


Powered by Movable Type 4.23-en