Posts Tagged ‘Dancer’

A new version of Dancer has been published to CPAN a few minutes ago, it’s also available from the official website, in the download section.

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.

I recently focused on Dancer’s core with a single target in mind: optimization.
After having heavily refactored the Dancer::Route class, I started benchmarking Dancer.

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.

I’m happy to announce the release of Dancer 1.150.

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.

Lots of good things happened recently in Dancer’s development, here they are:

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!

The discussion that is rising these days about frameworks and libraries reminds me I did not even take the time to talk about the last version of Dancer.
I should have, hence this post.

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.

Yes, I finally took the decision to stop using CGI.pm in Dancer’s code. It was not an easy decision to take, mainly because of the following reasons:

• 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… ;)

Sawyer X on blogs.perl.org recently wondered how one could run a Dancer application under a 100% CGI environment.

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 ;-)

A new version of Dancer has just been published on CPAN. It was a good time to do it, according to the changelog, as you can see:

    * 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!

I’m a big fan of Boxee, an open-source media center based on XBMC.

The Boxee iPhone application is great for remote control, but what if you’re with your laptop in front of your TV?

Wouldn’t it be great to be able to fire up a browser on your boxee host and be prompted by a web interface that provides the same features as the iphone app does?
This is what BoxeeRemote is, a lightweight webapp designed to control Boxee over the network.

You can use your mouse or your keyboard to send actions. Here is a screenshot of the current user interface (it’s a work in progress, and it lacks some key features such as volume control and playlist actions).

The current version allows you to navigate through the interface with the arrow keys, the backspace key and the enter key. You can also toggle Play/Pause with the space bar.

This is not released yet, but the source code is already available on my GitHub account, for those who care.

Oh, and the whole thing is written with Dancer, I guess it can be a good example for those who want to start writing a modern ajax-aware webapp with Dancer.

Well, here it is, after five months of development, Dancer is stable and feature-rich enough to be released as a shiny, stable, 1.000 version.

Major changes for this version are the following:

• Support for cookies
• Support for YAML-file-based sessions
• Support for Memcached-based sessions
• Support for Syslog logging
• Less dependencies than ever (only HTTP::Server::Simple and Exception::Class are mandatory to start writing a Dancer app)

The test suite has also been heavily enhanced, covering now more than 80% of the source code.

I’ve just uploaded the tarball to the CPAN, so expect it to be cpan-able in the next couple of hours.

I welcome very much feedback on this release, please feel free to give it a try ;)

Bugs reports are also welcome here.

Oh, and by the way, today is a special day ;-)