As you can see, the project has now its own domain name: http://perldancer.org, it’s clearly more shiny than the previous subdomain I used ;) So feel free to update your bookmarks (even though the old domain name now redirects to the new one).

Oh, and there is also a mailing list now, for people who like to share experiences about Dancer; feel free to join.

The change set for 1.160 is impressive, thanks a lot to everybody who got involved!

Happy dancing.

To start with, I’ve created a set of test applications, in order to bench different kinds of application (from a hello world app to a huge one).

All these applications are available in this repository, if you like to see more precisely what I did.

The first test I did was to bench a “hello-world” application, with PSGI, Dancer 1.150 and the last version of the master branch.

hello.psgi .................... 1420 req/s
hello.dancer (1.150) .......... 1260 req/s
hello.dancer (github/master) .. 1320 req/s

You can see that Dancer “master” is about 100 req/s faster than 1.150, this is mainly thanks to Dancer::Route::Builder: Dancer now compiles all the routes defined by the application at startup time, and don’t spend time whenever a request is handled to do that job.

Moreover, thanks to SawyerX, Dancer now caches route resolution via Dancer::Route::Cache, and that increases response-time drastically when accessing an application with lots of routes.

Here is another bench that I did against an application with 676 routes handlers.

big.dancer (1.150, no cache, no route compiler) ...  110 req/s
big.dancer (GH, no cache, route compiler) .........  130 req/s
big.dancer (GH, cache, route compiler) ............ 1300 req/s

It appears clearly here that with a big number of route handlers, Dancer’s response-time decreases. I wanted to see more precisely how that occurs, and I run a bench in order to compare the response-time when varying the number of route hanlders.

As you can see on this graph, thanks to route caching, we now have a roughly constant response-time, no matter how many route handlers we have in the applicaiton.

These improvements will be shipped with the next CPAN version, either 1.151 or 1.160 if we have the time to add some new features as well.

Stay tuned.

This release has been made possible by six people, so it’s quite the first community-driven release of Dancer, and nothing could make me more happy than that.

I really like the fact that different people, from different places come and contribute ideas, documentation and patches. This is how open source works, and this is how great tools are written. I’m glad to see Dancer taking that path. I can only hope that it will be like that for a long time.

This new version provides mostly bugfixes and documentation updates. See the changelog for full details. Oh, and thanks to David Precious, we now have a shiny Cookbook!

Major new features will come with 1.160, but that’s for another blog entry ;)

Enjoy your dances.

HTTP::Server::Simple::PSGI

After my last post about Dancer, Tatsuiko Miyagawa suggested to build Dancer’s standalone server upon a PSGI-aware layer, rather than on HTTP::Server::Simple::CGI.

A couple of days later, he released HTTP::Server::Simple::PSGI, which is actually based HTTP::Server::Simple (which itself doesn’t depend on any non-core modules).

A few patches later, the standalone server was refactored and running on this new guy. That means when writing a Dancer app, you can now always rely on PSGI environment goodness, whereas you’re using the standalone server, or the Plack architecture. That just rocks, again kudos to @miyagawa.

Dancer::Request

The Dancer::Request class got also heavily refactored and enhanced, it can now provide the user with an access to the raw body of the incoming request (thanks to RasterBurn for the report).

By the way, this class needs still so more features, and I’m actively working on it. I may release Dancer 1.2 when I’m happy with that one.

Oh and it also now provides a complete documentation. POD FTW.

Dancer::Route

I also gave a shot at Dancer::Route, which has been recently patched to support some new features (prefix and conditional matching, thanks to Frank Cuny)

No more CGI.pm, really!

I also found that CGI.pm was still used in one very place for rendering and HTML page. This was a shame as we wanted Dancer to be 100% CGI.pm-free. Hence the patch that actually allow us to say it now, for REAL ;)

All of this freash meat is available on my GitHub repo and will be soon released to CPAN, under version 1.140. Stay tuned!

Last version of Dancer, 1.130, is the first version which is “plugin-aware”.
That means since 1.130 anyone can write their own template, logger or session engine and rock the app by just setting the appropriate value to the corresponding setting.

The plugins that existed before the split have been extracted from the core distribution in order to be shipped separately, that’s much clean and makes more sense that way:

• Dancer : the core framework, plus essential plugins
• Dancer::Logger::LogHandler : logger engine for Log::Handler (written by Frank Cuny)
• Dancer::Template::MicroTemplate : template engine for Text::MicroTemplate (written by Frank Cuny)
• Dancer::Session::Cookie : session engine based on encrypted cookie (written by Алексей Капранов)
• Dancer::Session::Memcached : session engine based on memcached

If you have a template, logger or session engine you’d like to see in Dancer’s ecosystem, I invite you to take a look at the corresponding interfaces you have to implement, it’s pretty straight forward.

The concept is pretty easy, basically, here are the steps to follow to add a new engine:

• choose a setting name that is available for template, session or logger, according to what you’re doing.
• implement the interface of the engine you like (Dancer::Template::Abstract, Dancer::Session::Abstract, Dancer::Logger::Abstract)
• Name your class with a camelized version of the setting name

Here is an example, let’s say you have a great template engine you’d love to use for rendering your views in your Dancer app, let’s name it “HTML::IronMark”.

• First of all, create Dancer::Template::Ironmark which implements the interface Dancer::Template::Abstract
• Then change the setting template to "ironmark"

And well, you’re done. This is pretty much the same job for logger and session engines.

Feel free to contact me if you want to write your own and need more precisions.

Ah, I’m glad I’ll face a goban this evening, it’s been too long!

The first slot will be hard to reach though, because of that sourceforge page which has “perlwebserver” in its hostname.

• it’s in the core (I’m a “less-CPAN-deps-ships-better” freak when it’s about Dancer!)
• it provides a stable and well-known way of dealing with the HTTP interface (params, methods, path infos …)
• and well, to add a third reason, why should I want to change it if it works?

Well, actually, we did find a bug recently in CGI::PSGI that prevented a Dancer app from being deployed under Plack::Server::Apache2. Oh, of course, the bug was almost instantly fixed when it has been discovered (the #plack people are really reactive).

But that enlightened something: CGI.pm is old, really old, and that means, when you’re using it, you take with you a lots of lines of code coming from years ago. Moreover it is well known that CGI.pm does addresses different matters, such as providing a request interface and generating HTML content as well. Conceptually, it sucks.

After thinking about all that, I decided to drop CGI.pm out of Dancer’s code. I then have the option to use the pretty fresh Plack::Request interface. It looks really nice and does exactly what you can expect from it.

But, it’s important for me that Dancer can be used without Plack. I want the dependency barrier to be as low as possible:
If a user wants to test Dancer, he should not have to install Plack in my opinion. If he likes it, and wants to goes on production, then yes, Plack is a must-go. He then installs Plack and goes on with Dancer’s app.psgi.

So depending on Plack::Request was one more dependency I’d rather not add to Dancer.

With all this in mind I came to the decision to write Dancer::Request, reading carefully the PSGI specs (miyagawa++ again).

It was all good except for processing the POST data. There’s so much work to do when it’s about multipart form, url-encoded form, or even file uploads that I chose not to push the “reinvent-the-wheel” thing too far, and I decided to copycat Plack::Request on this topic: using HTTP::Body.

This module does the job pretty well, with an object-oriented interface.

The conclusion might look like a failure (I rewrote something that worked by adding a new dependecy.) But deep inside I’m happy with this refactoring; because Dancer is now on a way where all of its code will be fresh, based on PSGI specs and won’t ever rely on CGI.pm to do something.

I hope Dancer’s users/developers will agree with that. feel free to comment on this post if you want to share your point of views. Yes, I know this might trigger a troll or two… ;)

Indeed, he came up quickly with a REST app in development stage and wanted to go on air with a plain old CGI script. He seems to think it’s not possible with Dancer but as Dancer supports PSGI/Plack, he’s wrong ;)

Thanks to the PSGI/Plack goodness, any application can be powered by a Plack-supported server. CGI is one of them and is implemented by Plack::Server::CGI.

By taking a quick look at the POD, we see that all we have to do is to write a pretty simple CGI script to bridge the Dancer app with Apache:

#!/usr/bin/perl

use Plack::Server::CGI;
use Plack::Util;

my $psgi = '/path/to/your/app/app.psgi';
my $app = Plack::Util::load_psgi($psgi);
Plack::Server::CGI->new->run($app);

We now have to tell Apache that everything should be dispatched to that very CGI script like the following:

<VirtualHost ....>
	<Directory "/path/to/your/app">
		AllowOverride None
		Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
		Order allow,deny
		Allow from all
		AddHandler cgi-script .cgi
	</Directory>

	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteRule ^(.*)$ /dancer.cgi [QSA,L]

        [...]
</VirtualHost>

And… we’re done! Every request the Apache server catches is now served by Dancer through Plack::Server::CGI

All I have to say here is … Plack++ (or @miyagawa++ which seems to be the same ;-)

    * Support for multiple method routes at once with 'any'
    * Templates engines
      + Bug fixes in Dancer::Template::Simple (Jury Gorky)
      + Refactoring of the factory
      + option for disabling the layout in the template helper.
    * New session engine based on encrypted cookies (Alex Kapranof)
    * More HTTP codes supported for a better REST compat (Nate Jones)
    * Documentation updates
    * script/dancer now requires an appname
    * New Makefile.PL with better metadata (CPAN Service)

I’m pretty glad to underline that this release is the first one where most of the changes are written by other developers than me, that’s really exciting to see more and more people involved with the project.

This release should also fix the test-suite which looks to be broken on most of the CPAN testers under version 1.000 (but sadly not on my workstation, so I wasn’t aware of it).

UPDATE Jan. 7th 2010 : The CPAN-testers reports show that 1.100 passes 100% of the tests under Linux and FreeBSD, that’s a good start!
Stay tuned for next dances!