[cgiapp] Dancer

[P Kishor]

On Thu, Mar 4, 2010 at 8:49 PM, Mark Stosberg <mark at summersault.com> wrote:
> On Tue, 2 Mar 2010 13:38:15 -0500
> Mark Stosberg <mark at summersault.com> wrote:
>
>> On Thu, 25 Feb 2010 17:51:40 -0600
>> P Kishor <punk.kish at gmail.com> wrote:
>>
>> > following Mark Stosberg's email about PSGI, I decided to poke around a
>> > bit more, and landed up with Dancer. Color me very impressed.
>> >
>> > Seriously, I have seldom experienced such easy *everything*. Almost
>> > instant installation via 'sudo cpan Dancer', a simple 'dancer -a
>> > myapp', and I had a working, nice looking application framework [*]
>> > with nice URIs and ev'ryting.
>> >
>> > So, my question is thus -- how is Dancer different from CGI::App, and
>> > why should I use the latter instead of the former? I asked this not
>> > lightly because I have many years of experience invested in C::A, but
>> > Dancer truly shows how apps should be.
>>
>> I had already looked at Dancer myself. As a result, you can see these
>> entries in the Dancer ChangeLog:
>>
>>     * Security Fix: protection from CRLF injection in
>>       response headers (thanks to Mark Stosberg for the report).
>>     * Support for multi-valued params in GET/POST data (thanks to
>>       Mark Stosberg for the report).
>>
>> So, in a short review, I found that it lacked support for multi-valued
>> params, and that it had a notable security hole. If you look into it
>> deeper, what else might you find?
>
> I should qualify my further comments further. CGI.pm also had a similar issue
> with allowing CRLF injection attacks in some cases, as did CGI::Simple. It's
> not what I would call a security vulnerability in any case because you
> have to write code that would be "tainted" for their to be a problem-- you would have to
> take untrusted data and use it to a build a header without first
> validating it.
>
> The issue with Dancer here speaks more to choice of "rolling their own" instead
> of re-using. So, when CGI.pm and CGI::Simple get upgraded,
> CGI::Application is able to take advantage of those improvements automatically, but
> Dancer does more in-use. That is fine if Dancer turns out to have
> everything correct and complete.
>
> The issue with missing support for multi-valued params I think is just
> a sign of it being a young and evolving project at the time I reviewed it.
>


Thanks for your insight Mark. Very useful.

I am still using my trusted CGI::App framework, and enhancing it, but
I am also following Dancer very keenly. Seriously, Dancer is a breath
of fresh air, part of the new line of apps such as Plack and its ilk,
Mojolicious::Lite and the kind.

Alexis Sukrieh, Dancer's creator, has a blog post on his logic for
abandoning CGI.pm, and I see nothing wrong with it. Frankly, I never
really did use CGI.pm. I always used CGI::Simple, and then, I never
really used anything that CGI::Simple provides other than grabbing the
get and post variables. I always did my own HTML development using
HTML::Template (Dancer doesn't have HTML::Template support for now,
but it should only be a matter of time), and have moved more and more
toward using jQuery on the front-end. If I can do without the several
thousands of lines of CGI.pm, well, so be it.

CGI::App is great, and should continue to be great, but more
competition, even friendly competition amongst free and open source
frameworks will only be good overall.

Here is what I want in a web framework --

1. clear and complete documentation

2. easy download and install without tortuous cpan deps nightmare and
compilation

3. built in webserver that can be changed to Apache/Lighty/FCGI,
whatever, with minimal lines of code.

4. readymade scaffolding to get started

5. clean URIs (routes) without screwing around with bazillion settings

6. a couple of popular templating system support

Both CGI::App and Dancer have that. CGI::App has the maturity and test
of time, Dancer has the freshness of the new debutante on the dance
floor.

Good for all of us.


-- 
Puneet Kishor http://www.punkish.org
Carbon Model http://carbonmodel.org
Charter Member, Open Source Geospatial Foundation http://www.osgeo.org
Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor
Nelson Institute, UW-Madison http://www.nelson.wisc.edu
-----------------------------------------------------------------------
Assertions are politics; backing up assertions with evidence is science
=======================================================================