Re: [Dancer-users] Dancer-users Digest, Vol 10, Issue 50
Naveed, I've used both and my take is ... Since Catalyst is meant to be used for large web apps, the scaffolding tool builds a better foundation with good emphasis on MVC, how you should the components and where to place them. Since the latest runs on Plack as does most everything else, there is no real performance difference. In-Short .. the MVC-ness of Catalyst is the only benefit I can think of. I hate when people throw the term "scale" or "web-scale" around ... WTF does that mean? ... its vague enough that it could refer to any number of factors. Most good object-oriented code will "scale" as that its purpose .. other factors such as platform, database, web server, etc (and their respective scalability) have nothing to do with the frameworks scalability. On Thu, Dec 30, 2010 at 6:00 AM, <dancer-users-request@perldancer.org>wrote:
Send Dancer-users mailing list submissions to dancer-users@perldancer.org
To subscribe or unsubscribe via the World Wide Web, visit http://www.backup-manager.org/cgi-bin/listinfo/dancer-users or, via email, send a message with subject or body 'help' to dancer-users-request@perldancer.org
You can reach the person managing the list at dancer-users-owner@perldancer.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Dancer-users digest..."
Today's Topics:
1. Re: Questions for Perl Survey (Olaf Alders) 2. Re: Questions for Perl Survey (sawyer x) 3. Catalyst vs Dancer (Naveed Massjouni) 4. Re: Catalyst vs Dancer (Puneet Kishor) 5. Re: CGI/FCGI deployment & uri_for (Robert Olson) 6. flash implementation (???? ??????????)
----------------------------------------------------------------------
Message: 1 Date: Wed, 29 Dec 2010 11:49:53 -0500 From: Olaf Alders <olaf@wundersolutions.com> Subject: Re: [Dancer-users] Questions for Perl Survey To: sawyer x <xsawyerx@gmail.com> Cc: dancer-users@perldancer.org Message-ID: <5F44E6BE-896E-4D31-9AB4-4CF8275C06D7@wundersolutions.com> Content-Type: text/plain; charset=us-ascii
On 2010-12-29, at 5:48 AM, sawyer x wrote:
Dancer provides a thin layer above PSGI and abstraction for some of the work a user would have to do manually (sessions, templating, finding out what type of HTTP method it is, setting the content type, etc.). You (or rather, Dancer, if that's what you're using) provide PSGI with an app handler subroutine. For example: sub app { my $env = shift; return [ '200', [ 'Content-Type' => 'text/plain' ], [ "Hello World" ], # or IO::Handle-like object
];
} How many people would do that? Very few.
True! However, I'd be interested in seeing how many people are writing their own Plack::Middleware components. As it's a nice and easy way to replace a lot of work you normally might be forced to write with mod_perl handlers, I would expect that the use of custom Middleware should rise over time as well.
Olaf -- Olaf Alders olaf@wundersolutions.com
http://www.wundersolutions.com http://twitter.com/wundercounter
866 503 2204 (Toll free - North America) 416 944 8306 (direct)
------------------------------
Message: 2 Date: Thu, 30 Dec 2010 00:44:44 +0200 From: sawyer x <xsawyerx@gmail.com> Subject: Re: [Dancer-users] Questions for Perl Survey To: Olaf Alders <olaf@wundersolutions.com> Cc: dancer-users@perldancer.org Message-ID: <AANLkTime+W5EmthCa6HoS5L47UZF9w_O2AAKrjUzORp6@mail.gmail.com<AANLkTime%2BW5EmthCa6HoS5L47UZF9w_O2AAKrjUzORp6@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Dec 29, 2010 at 6:49 PM, Olaf Alders <olaf@wundersolutions.com
wrote:
[...] I'd be interested in seeing how many people are writing their own Plack::Middleware components.
Good idea!
I would expect that the use of custom Middleware should rise over time as well.
That would be an interesting/useful metric.
On Thu, Dec 30, 2010 at 9:12 AM, Al Newkirk & Associates <we@ana.im> wrote:
I hate when people throw the term "scale" or "web-scale" around ... WTF does that mean? ... its vague enough that it could refer to any number of factors.
Good point. When I think of scaling, I think in terms of things like ease of clustering/load-balancing, use of centralized/shared caching (eg memcached), robust DBI connections for different configurations (eg Master-Master or Master-RW with a cluster of Slave-RO nodes), etc. Since Dancer is so good at remaining a micro-framework, many of these choices are in the hands of the coder rather than these choices being made for them by the framework. Since Dancer doesn't dictate those choices (thank you!) maybe the Cookbook or some Plugins could fill in the leap of imagination required for those who want to envision Dancer in a scalable context. By providing some best practices, cookbook recipes and deployment howtos, the Dancer community gets to define what scaling means to Dancer. My two cents.
participants (2)
-
Al Newkirk & Associates -
Mike Schroeder