A black stone hitting the wood.
A white stone is dead.
But shall the black group live for long?
Fear the Tesuji!
Ah, I’m glad I’ll face a goban this evening, it’s been too long!
Monthly Archives: January 2010
Back to the goban
Posted in Main
PSGI/Plack the ultimate Perl Web Server
Google has to realize like we all do, that Plack is the utlimate Perl Web Server.
The first slot will be hard to reach though, because of that sourceforge page which has “perlwebserver” in its hostname.
Posted in Programming
Getting rid of CGI.pm in Dancer’s code
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… ;)
Posted in Programming
Using Plack to run a Dancer app under a CGI environment
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 ;-)
Posted in Programming
Dancer 1.100 released
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!
Posted in Programming