For the next few months I worked through the process of turning the proof of concept into something core-worthy. Primarily that meant removing PlebGUI’s faked Apache2::Request object, completely eliminating any mod_perl dependencies from the WebGUI core and instead baking in WebGUI::Request and WebGUI::Response which are thin layers over Plack::Request and Plack::Response.

By about April most of the basic pieces were in place, performance was looking good, and I’d started the fun task of refactoring WebGUI to take advantage of the value-add features that Plack brings such as Middleware and stealing liberally from other Plack projects such as Tatsumaki‘s streaming API. But there was still lots of work to be done getting the test suite passing again and smoothing off the rough edges. Progress was slow due to my work commitments and frequent travel.

Then three of the main WebGUI committers got involved, first haarg++, then perlDreamer++ and preaction++. The pace accelerated dramatically. This week we officially merged the PSGI branch into the main development branch, meaning that the next major release of WebGUI will officially be a PSGI app!

Huge credit and thanks to haarg, perlDreamer and preaction (and anyone else who contributed too) for getting us over the hump. These guys are also the main driving force behind the other awesome features that are being baked into WebGUI 8, so if you like anything you see in the next version, make sure you buy them a beer or two.

Here are some screenshots of WebGUI with the Plack::Middleware::Debug bar turned on.

Previously, in debug mode WebGUI would append all debug output to the bottom of the page. Now, thanks to haarg’s custom Plack::Middleware::Debug panels, debug messages are contained within the “Logger” panel. Notice also the “Asset Performance” panel, which displays WebGUI::Asset performance metrics. This is only the beginning.

It’s such a buzz to have the PSGI branch merged in; now the real fun starts! I’ll be speaking about the WebGUI PSGI branch at the WebGUI User Conference in Madison in September, and at the rate things are going, who knows how much fun stuff we’ll be able to show off..

I’m also really looking forward to attending YAPC::NA next week (my first YAPC on American soil) and meeting/hanging out with lots other people who have been doing awesome things in the Perl web app space (and beyond). Vive la renaissance Perl!

# app.psgi
use Plack::App::JSP;
Plack::App::JSP->new( js => q{
[ 200, [ 'Content-type', 'text/html' ], [ 'Hello, World!' ] ]
});

# displays: Hello, World!

Given the similarities between Perl and JSON you can’t actually tell if I’m cheating or not from the above snippet.

Let’s try something more convincing:

Plack::App::JSP->new( js => q{
function respond(body) {
    return [ 200, [ 'Content-type', 'text/html' ], [ body ] ]
}

respond("Five factorial is " +
    (function(x) {
      if ( x<2 ) return 1;
      return x * arguments.callee(x - 1);
    })(5)
);
});

# displays: Five factorial is 120

I just pushed Plack::App::JSP to the CPAN.
Thanks to Salvador Ortiz and Miguel Ibarra whose recently released JSP module makes this possible.

So, perlsharedhosting.com is now officially up and running.

Rather than wasting my time building a web app for the site before the idea has been proven, I decided to use a simple CMS and focus my energies on the content instead (there’s a wonderful irony in using a PHP CMS to deliver content about Perl shared hosting..).

I’ve added quick-start guides on how to install the following core technologies on your shared hosting account:

• local::lib
• cpanminus
• Task::Kensho (the “We support modern Perl” badge of honour for hosting providers)
• Plack
• Dancer

These pages are not in any way supposed to replace the official documentation sources. Ideally, they just tell you what the tool/lib  is, why you need it, and how to install it with minimum fuss. In reality, we also need to list any issues you may run into when using them in a shared hosting environment, but the idea is that we feed this information back to the upstream projects so that workarounds become unnecessary.

I’ve tested two different hosting providers, neither of which I’m going to mention by name here because I’m not trying to actually promote their brand.

• The first one had a major limitation – no access to cc and hence the inability to compile XS modules (their tech support has offered to install CPAN modules on request, but it’s less than ideal).
• The second one has so far passed all tests with flying colours – “cpanm Task::Kensho” works flawlessly, including all the XS modules. This is perhaps not all that surprising given that this is the same hosting provider that I used last year to get WebGUI running under PSGI on a shared account.

I started playing with Dancer for the first time, and soon had live demos of Dancer running in both CGI and FastCGI modes. Those URLs will change in the future but the idea is that we set up live versions of each web framework running on each hosting provider. Maybe in the future we could use a monitoring service to track the reliability and response time of each combination.

So already, the Perl Shared Hosting site has step-by-step instructions for how to run Dancer web apps on a shared hosting account for less than six bucks per month. That’s not half bad.

If you have a shared hosting account on a provider that isn’t listed (or you work for a shared hosting company and want to get yourself listed) then please contact me to get involved.

Next up, we need to add more information about resource limits. I also plan on adding more web frameworks such as Web::Simple, MojoMojo, Catalyst, Tatsumaki, ..

Once we have an idea about what features are most important, I’d like to then turn it around and start contacting the providers to ask them if they will add support for certain features to match (or beat) their competitors. I think there’s real potential for communicating back to the shared hosting providers that there’s a large market for modern Perl hosting, and ideally, what features we need/want. The site may also be useful for feeding back to the Perl toolchain/framework people what rough edges people are running into in shared environments.

Recently Padre::Plugin::Plack, my Plack (the Perl Web Server) plugin for Padre (the Perl IDE) was translated into Dutch, Brazilian Portuguese and French.

I always get such a buzz when I find out that something I’ve worked on has been translated into another language. It sends a clear message that someone found your work useful enough to go to the effort of translating it so that a new community of people could use it. That’s an awesome form of positive feedback, and a great motivator for being involved in open source software.

Thanks translators!

Here’s a silly example:

# A Perl one-liner for the iPhone generation
plackup -MPlack::App::Directory -e 'builder {enable iPhone; Plack::App::Directory->new}'

That makes your current directory browsable as a web app, with some special iPhone meta tags injected so that the viewport is appropriately resized & fullscreen mode is enabled when you launch your “app” from your Home Screen.

Here’s a slightly more usable one – your own personal mobile.search.cpan.org:

plackup -MPlack::App::Proxy -e 'builder {enable iPhone; Plack::App::Proxy->new(remote => "http://search.cpan.org/") }'

You can customise things too:

# app.psgi
use Plack::Builder;
use Plack::App::Proxy;
builder {
    enable "iPhone",
        statusbar => 'black-translucent', # transparent status bar
        startup_image => 'loading.png', # displayed as the app loads
        icon => 'icon.png'; # cutom app shortcut icon
    Plack::App::Proxy->new(remote => "http://search.cpan.org/");
};

Here’s an actual app that I have running on my phone to display the New York subway map (images courtesy of the MTA website):

<!-- index.html -->
<html>
    <head>
        <title>NYC Map</title>
        <style>
            body, img { margin: 0; padding: 0; }
        </style>
    </head>
    <body>
        <script>
            window.scrollTo(300, 700); // Initially zoom in on my local area
        </script>
        <img src="sub1a.gif">
        <img src="sub2a.gif">
    </body>
</html>

# app.psgi
use Plack::App::Directory;
builder {
    enable "iPhone",
        icon => 'icon.png',
        manifest => 1,
        viewport => 'initial-scale = 1, maximum-scale = 1.5, width = device-width',
        statusbar => 'black-translucent',
        startup_image => 'loading.png';
    Plack::App::Directory->new;
};

Use plackup to run the site on your local network, connect via Safari on your iPhone (via wifi) and then use the “Add to Home Screen” option to add an app shortcut to it on your phone. Your 57×57 icon.png image will be used as the app icon, and your 320×460 loading image will appear as the app loads. The viewport string sets the initial zoom scale and limits how far in the user can zoom. Nice and shiny.

With the manifest option enabled, Plack::Middleware::iPhone automatically generates a manifest file and injects the appropriate html to enable HTML5 offline web app caching on your iPhone. This means that your app keeps working once you Ctrl-C the plackup server and walk out your front door. And it keeps on working when you’re stuck in the New York subway system without phone reception, trying to figure out what train you’re supposed to catch to get home.

If you’ve just started exploring how to build iPhone apps with web technologies, I suggest you check out Jonathan Stark’s book “Building iPhone Apps with HTML, CSS, and JavaScript” (online here).

Latest Web::Simple master (git://git.shadowcat.co.uk/catagits/Web-Simple.git) is now using Plack, the perl web server directly for CGI and FastCGI and I hope do do another release shortly with notes on deploying as both on shared hosts (more specifically Dreamhost but with an invitation to bitch if they don’t work on other budget hosts).

mst,  ”Oh Subdispatch, Oh Subdispatch“

Every time someone mentions a cool new web framework like Web::Simple, Dancer or Tatsumaki, my immediate reaction is to start thinking up cool little niche web apps I could build with it. You know, the kind you imagine yourself whipping up during your lunch break, that will probably never get more than 10 curious users but just might turn into the next big thing if only you got it up and running on a public server. And that’s when the second thought immediately arrives: where am I going to run this thing? Do I really think the idea has enough legs to justify paying for a virtual server plan? Can I be bothered going through the pain of figuring out how to deploy it on a shared hosting provider? And normally that’s the point where I sigh wistfully and go back to reading my RSS feeds.

The thing is, with the advent of things like local::lib it’s getting a lot easier to deploy Perl web apps on shared hosting. And with most web frameworks adopting Plack/PSGI, the work required to deploy Perl web apps on budget hosts is converging into a similar sequence of steps.

So this time during my lunch break I started envisaging a centralised, SEO-friendly information source (hello perlsharedhosting.com) that cobbles together all of the currently available information into an easy to digest form to make it ridiculously easy to choose a shared hosting provider, deploy your web app and troubleshoot common problems.

A site that works like this:

• The front page contains a list of Perl-friendly hosting providers, with a meta-score based on how many features they support (+) and how many unresolved issues they have (-), and maybe user review scores thrown into the mix too
• Each hosting provider has a page of its own, listing in full which features are supported (used to compute the meta-score). Users can post comments on each of these pages, to leave testimonials (“I am currently running a Web::Simple site that gets x hits per hour on this host”) and note unresolved issues (“module X::Y fails to install on this host”). As issues get solved these become tips.
• Each technology/feature/technique also gets a page of its own, with links to the official man pages, shared-hosting specific notes and again user comments
  • dependency related: local::lib, cpan, cpanm, ..
  • environment related: locating and running perl, paths, daemons, viewing error output, ..
  • web deployment related: CGI, FastCGI, ..
  • framework / web app related: Web::Simple, Dancer, MojoMojo, Catalyst, Tatsumaki, ..

I haven’t decided yet what engine would fit best.. MojoMojo is a front-runner, and in fact the Catalyst Friendly Hosting page runs on MojoMojo does a large chunk of what I’ve described above.

The site would be very “cookbook” oriented, since we’re specifically targeting people who can’t be bothered learning the ins and outs of 10 different technologies (not to mention figuring out how to get them to play nicely together) for the sake of deploying toy web applications on cheap shared hosting. Just the essentials: this is what you need, this is how you achieve it. And if you want to learn more, go here.

With that in place, we’d end up with a single, visible, place to research and document the complications of running Perl web apps on shared hosting. And if the site became popular, hosting providers might even take notice and start offering more Perl-friendly shared environments. We could have live demo pages running on different hosts, possibly even donated by hosting providers if they see it as a way of showcasing their Perl-friendliness (mojomojo.dreamhost.perlsharedhosting.com, dancer.resellerzoom.perlsharedhosting.com, etc..).

I got as far as registering the domain name; I was planning on getting a simple MojoMojo prototype up and running, but I got side-tracked researching how to deploy it on my shared hosting account…

As the name suggests, Padre::Plugin::Plack adds Plack awareness to Padre. With the plugin installed, opening *.psgi files causes some special things to happen. PSGI files are really just ordinary Perl files, so Padre does its normal Perl lexing/syntax highlighting magic on them, but the real fun starts with the Plack-specific features that appear in the per-file graphical plackup control panel that shows up. The panel lets you run your web app in a Plack server at the click of a button, view server output, configure plackup options and launch a web browser on the appropriate port.

The great thing about Plack/PSGI is that unlike my previous plugin (Padre::Plugin::WebGUI) which was specific to a single web app (albeit a big one), this plugin can be used for any web app built in a web framework that supports Plack (Catalyst, CGI::Application, HTTP::Engine, etc..). This potential for cross-framework application is one of the motivating factors that makes developing Plack modules (Middleware etc..) so much fun.

The plugin turns on plackup’s “–reload” option by default, which conveniently causes the plack server to reload every time you modify your source files in Padre. This makes for quite a nice, if somewhat minimal “Plack IDE” experience (this is version 0.01 after all).

The plugin integrates all of the Plack example “dot-psgi” files as templates that can be used to create different types of Plack apps straight from the GUI menu.

The pre-populated list of Plack servers and the simple start/stop button makes for a nice way of exploring the Plack server ecosystem. You can use the other panel options to enter a specific port to run on, toggle auto-start mode and pass additional options to plackup (options that start with “–” are passed through to the backend server).

The output panel is similar to the output panel that Padre normally displays when you execute Perl files, except that you get one panel per .psgi file meaning that you can run multiple plack servers simultaneously and independently view their output. The appropriate panel is automatically selected when you click on the corresponding file tab, and running processes are stopped when you close the tab.

It should be really easy to turn Padre::Plugin::Plack into new plugins that involve the same basic ingredients, namely  a file extension and an external command for running those files, with a per-file panel for command options and output. So I encourage anyone who has a similar plugin in mind to steal liberally from Padre::Plugin::Plack (as I did from Padre::Plugin::Catalyst – thanks garu++). Ruby Rack support comes to mind as a trivial example.

Make Padre your domain-specific IDE today

Plack has a really neat solution to this problem.

Following a tip from day #5 of Miyagawa’s Plack advent calendar, serving up the current directory over http is as simple as this Perl one-liner:

$ plackup -MPlack::App::Directory -e 'Plack::App::Directory->new

Plack::Server::Standalone: Accepting connections at http://0:5000/

Or if you need the files served over port 80:

$ sudo plackup -MPlack::App::Directory -e 'Plack::App::Directory->new' -p 80

Plack::Server::Standalone: Accepting connections at http://0:80/

I got a kick out of seeing Miyagawa pull up my blog post on PlebGUI in response to someone’s question about porting mod_perl applications (e.g. apps that pass around an Apache $r object) to Plack. For the sake of the guy who asked the question, the way I did it (at least for the first pass) should be equally viable for other mod_perl applications – just create a fake Apache $r object that delegates everything to Plack::Request and Plack::Response (your mileage will obviously vary depending on how much of the mod_perl API your app uses).

But you see mod_perl is an overly zealous lover. Every intimate phase of the Apache request cycle is offered up to your eager Perl embrace. Sure, you have to learn a few new tricks to get decent performance (such as two-tier mod_proxy/mod_perl) but hey it’s 2001 and mod_perl is SO much better than CGI. Without hesitation you commit to a life of PerlResponseHandlers and Apache2::Const::OKs.

Years pass. Life is good.

Your user base had become very adept at deploying Apache. In fact you make life easier for them by distributing the complete Perl/Apache/MySQL stack as a simple installer, pre-configured for optimum performance.

Every now and then someone appears on the mailing list asking questions about WebGUI 5, a throw-back to the days when it used to be possible to deploy WebGUI on cheap shared hosting cPanel servers in CGI mode. You want to help, but WebGUI has become so powerful that CGI mode isn’t feasible anymore. That’s the price that was paid for evolving into an Enterprise-grade system. Developers lament the fact that small-time users can’t take advantage of all the awesome things WebGUI can do, not to mention all the word-of-mouth promotion WebGUI is missing out on, but them’s the brakes. WebGUI continues to grow. “Carrier-grade” is the new black. And across town, the non-enterprise crowd is left to content themselves with WordPress, Joomla and Drupal.

And then a guy called Tatsuhiko Miyagawa comes along.

He says, gee, look at these wonderful server abstractions that Python (WSGI) and Ruby (Rack) have. The Perl world might have moved on from CGI to things like Catalyst::Engine::* and HTTP::Engine, but there’s still duplicated effort everywhere. We can do better.

So he sits down and writes PSGI, an absurdly simple, manifestly beautiful specification for an interface between Perl web apps and web servers (drawing heavily on WSGI and Rack for inspiration).

PSGI

The idea goes like this: Web applications, when all is said and done, are really just on about sending three pieces of information to web browsers: a HTTP status code, a list of HTTP headers, and some content (a file or some text, normally HTML).

This is the specification:

[                                           # an array ref, containing..
    200,                                    # a HTTP status code
    [ 'Content-Type' => 'text/html', .. ],  # an array of HTTP headers
    [ '<html>...</html>' ],                 # the text content (or a $filehandle)
]

And that’s really all there is to it.

Some people write web apps according to the interface. Other people write server backends according to the interface. Web app developers use whatever whiz-bang technology they like, and as long as they return an array that complies with the spec their web app can run on any server. And server backend developers can do lots of clever things to get that information back to web browsers really fast, and have the results of their work benefit all PSGI/Plack consumers. No more duplicated effort. No more server-specific love lock-in.

And folks took notice. Not just any folks either. Really, really smart people like Yuval Kogman, Stevan Little, Shawn Moore, Matt Trout, Jesse Vincent, Chia-liang Kao, Dave Rolsky, Simon Cozens, ..  (They’re some of the well-known names that jumped out at me from the PSGI.pod spec doc. The others are probably even smarter, stealth hackers. I know, it’s scary).

Plack

Before you could say Plack there was a reference implementation, server backend support for CGI, FastCGI, mod_perl (welcome back!), AnyEvent, Coro, Perlbal, Nginx, .. framework support for Catalyst, CGI-Application, Mason, Continuity, Maypole, Mojo .. and a whole suite of Middleware and Utilities.

Meaning that all of a sudden any web app written in one of those frameworks can now be deployed on any of those servers. Or on the pure-perl standalone server that runs from the command line. Or on one of the more experimental/exotic servers I haven’t listed. If you’re not excited yet, just wait until Google AppEngine appears in that list.

WebGUI

But where is WebGUI! The problem is that WebGUI is both a framework and a web app. A really big web app. With a mod_perl addiction. Frameworks are built with multiple servers in mind, so they generally already have an in-built server abstraction layer. Which makes adding PSGI support relatively simple. WebGUI, on the other hand, deliberately eschews an abstraction layer so that it can fully embrace mod_perl and eke out every last ounce of power and performance it can from Apache.

So, faced with extreme framework envy, I did what any reasonable person would do.

I built a PSGI/Plack layer for WebGUI.

PlebGUI

I’ve codenamed the project “PlebGUI“, which I think aptly describes the way it makes it possible for the little people to run WebGUI on low-cost shared hosting.

And it actually works. Take for instance plebgui.patspam.com, a demo PlebGUI site site running in FastCGI mode on HostMonster (the prototypical low-cost shared webhost).

app.psgi

The second wonderously simple idea in the PSGI spec is that a web app is just a plain old perl subroutine. Here’s one I prepared earlier:

sub { [ 200, [ 'Content-Type' => 'text/html' ], [ 'Hello World' ] ] }

I know, it’s almost insulting. I’m a web developer man! I do sophisticated things! But try putting that single-line sub into a test file called app.psgi. And then after you’ve installed Plack (it’s not on CPAN yet so you have to install it from miyagawa++’s git repo) try running this:

$ plackup
Accepting connections at http://0:8080/

Go on, visit that url in your web browser. Hello to you too!

Middleware

Ok that was a cute trick, let’s try something more exciting:

use Plack::Builder;
builder {
    add "Plack::Middleware::Static", path => qr/./, root => '/var/www';
    sub { [ 404, [ "Content-Type" => "text/plain" ], [ "Not Found" ] ] };
};

Congratulations, you just added your first Middleware. Assuming you have some static files located at /var/www, you’ll get the static files returned to your browser with the correct mimetype (thanks to Plack::Middleware::Static). Middleware just wraps your web app (a plain old Perl sub) with another plain old Perl sub. Middleware can do logging, pretty HTML stack traces, pre/post processing, or anything else you like. Simple, but immensely powerful.

Plackup

Plackup is a simple utility script that launches your web app with a specified server backend. By default it runs the pure-perl standalone development server. It expects your webapp to live in a file, similar to the ones we just created. Want to run your web app on another server backend? Try one of these:

plackup                                         # dev server with StackTrace and AccessLog enabled
plackup -s CGI                                  # remember how slow web apps used to be?
plackup -s AnyEvent                             # nonblocking
plackup -s Coro --port 9090                     # coroutines
plackup -s Standalone::Prefork --max-workers 20 # blazingly fast preforking ftw!

dev.localhost.localdomain.psgi

Here’s what the current per-site .psgi file looks like for PlebGUI:

use Plack::Builder;
use lib '/data/WebGUI/lib';
use WebGUI;

builder {

 # Populate $env from site.conf
 add 'Plack::Middleware::WebGUI',
   root => '/data/WebGUI',
   config => 'dev.localhost.localdomain.conf';

 # Handle /extras via Plack::Middleware::Static
 add 'Plack::Middleware::Static',
   path => qr{^/extras/},
   root => '/data/WebGUI/www';

 # Handle /uploads via Plack::Middleware::WGAccess (including .wgaccess)
 add 'Plack::Middleware::WGAccess',
   path     => qr{^/uploads/},
   root => '/data/domains/dev.localhost.localdomain/public';

 sub { WebGUI::handle_psgi(shift) };
}

What you can see there are 3 Middleware layers added in, one to set up the WebGUI site-specific environment, one to handle /extras static content, and one to handle /uploads static content (taking into account .wgaccess file permissions).

All of those plackup command variations above can be used to launch WebGUI outside of mod_perl. Prefer running inside of Apache? How about one of these:

<VirtualHost *:80>
 PerlOptions +Parent
 PerlSwitches -I/data/WebGUI/lib

 # CGI
 #AddHandler cgi-script cgi
 #ScriptAlias / /data/WebGUI/etc/dev.localhost.localdomain.cgi/
 #<Directory /data/WebGUI/etc>
 #   Options +ExecCGI
 #</Directory>

 # mod_perl
 #SetHandler perl-script
 #PerlHandler Plack::Server::Apache2
 #PerlSetVar psgi_app /data/WebGUI/etc/dev.localhost.localdomain.psgi

 # FastCGI
 FastCgiServer /data/WebGUI/etc/dev.localhost.localdomain.fcgi
 ScriptAlias / /data/WebGUI/etc/dev.localhost.localdomain.fcgi/

 # mod_psgi
 #<Location />
 #    SetHandler psgi
 #    PSGIApp /data/WebGUI/etc/dev.localhost.localdomain.psgi
 #</Location>

</VirtualHost>

Using those directives you can run WebGUI in CGI, mod_perl, FastCGI mode, or even the in-development mod_psgi Apache module.

Benchmarks

Ok so how fast are these different backends? Let’s use ApacheBench to do some simple, unscientific tests of how many requests per second we can squeeze out of WebGUI.

First we’ll start with WebGUI in its original, un-plebified form, running on the WRE (more is better):

$ ab -n 1000 -c 10 -k http://dev.localhost.localdomain:8081/ | grep ‘Requests per’
Requests per second:    122.77 [#/sec] (mean)

The result is of course completely dependent on your Apache configuration – in this case I have (StartServers, MinSpareServers, MaxSpareServers, MaxClients) = (5,5,10,20).

Ok, now have a look at these numbers:

$ ./ab.pl –app /data/WebGUI/etc/dev.localhost.localdomain.psgi
Testing implementations: AnyEvent, Standalone, Standalone::Prefork, ServerSimple, Coro
app: /data/WebGUI/etc/dev.localhost.localdomain.psgi
ab:  ab -n 1000 -c 10 -k
URL: http://127.0.0.1/

– server: AnyEvent
Accepting requests at http://0.0.0.0:10001/
Requests per second:    68.06 [#/sec] (mean)

– server: Standalone
Accepting connections at http://0:10001/
Requests per second:    64.92 [#/sec] (mean)

– server: Standalone::Prefork
Accepting connections at http://0:10001/
Requests per second:    214.54 [#/sec] (mean)

– server: ServerSimple
Plack::Server::ServerSimple: You can connect to your server at http://localhost:10001/
Requests per second:    66.43 [#/sec] (mean)

– server: Coro
2009/10/11-23:17:32 Plack::Server::Coro::Server (type Net::Server::Coro) starting! pid(1581)
Requests per second:    67.55 [#/sec] (mean)

Did you see that? Standalone::Prefork is almost twice as fast as WebGUI in the WRE! The pre-forking server’s max-workers setting defaults to 10, so the comparison might actually be fair too.

Holy Shit

I think that’s worth repeating. PlebGUI, which is currently less than one week old and running on a compatibility layer optimised for “let’s just get this thing working and worry about performance later” is already capable of out-performing the WRE in terms of raw speed by 200%. (If you believe the benchmarks).

But Plack/PSGI is not just about speed. It’s about flexibility. Think Koen de Jonge, WebGUI hosting extraordinaire at Procolix, deploying a high availability “follow the sun” WebGUI cluster on Nginx servers. Think Colin Kuskie, WebGUI test suite overlord, probing the dark corners of the WebGUI API using standard HTTP::Request and HTTP::Response pairs through mocked HTTP and live HTTP servers. Think web developers working on WebGUI client code, with a web server fully integrated into Padre. Think WebGUI entirely deployable from the CPAN.

Think of every new project added to the PSGI/Plack ecosystem as a potential new PlebGUI feature.

Where to Now

The approach I took in turning WebGUI into PlebGUI was to create a fake Apache2::Request object, since that’s the closest thing WebGUI has to a server abstraction layer. Plack contains two helper classes Plack::Request and Plack::Response that make this really easy. Currently though, that leaves us in the curious situation where WebGUI does all of its work thinking it’s talking to mod_perl, only to have its real output re-routed through the PSGI-compatibility layer, to be subsequently processed by a specific server backend. If you don’t get the joke yet, just think about what happens when the PSGI server backend happens to be mod_perl.

The benchmarks would clearly improve if we ripped out mod_perl altogether. Lots of code would simplify too. Certain parts of WebGUI could disappear altogether, such as URL Handlers which could be entirely replaced with Middleware.

The only feature that PlebGUI currently lacks is content streaming. I deliberately left that out since it will be a lot easier to achieve once mod_perl disappears. In Plack land the way to drip-feed browsers with “chunked” content is to return an IO::Handle-like object that responds to getline() and close(). The Plack folks are planning a fancy new module called IO::Writer that will Do The Right Thing under both blocking and non-blocking servers. Expect awesome things.