Bug #52756 for CGI-Application-Dispatch: wish: PSGI/Plack support

Mon Dec 14 10:00:57 2009 MARKSTOS [...] cpan.org - Ticket created

CC:	miyagawa [...] gmail.com
Subject:	wish: PSGI/Plack support

CGI::Application::Dispatch needs to be updated to support PSGI/Plack. See the thread below. Mark Begin forwarded message: Date: Sat, 12 Dec 2009 20:02:22 -0800 From: Tatsuhiko Miyagawa <miyagawa@gmail.com> To: Kazuho Oku <kazuhooku@gmail.com> Cc: mark@summersault.com Subject: Re: Adding CGI::App::Dispatch support to CGI::App::PSGI Hi, Personally I'm fine with having two dists, as long as both reference each other in their documentations, explaining when you should use which. Also Mark, it'd be nice if CGI::Application::Dispatch can be upgraded to add PSGI support natively via CGI::Application::PSGI in some way. Currently it seems the API (not using ->run?) seems incompatible and it does functional style calls to CGI like CGI::path_info() which makes it incompatible to CGI::PSGI. Not being a CGI::App user, just my 2c. Thanks! On Sat, Dec 12, 2009 at 7:24 PM, Kazuho Oku <kazuhooku@gmail.com> wrote: Show quoted text

> Hi, > > I have written a module called CGI::Application::Emulate::PSGI. > http://github.com/kazuho/CGI-Application-Emulate-PSGI > > It is an PSGI adapter for CGI::App, but is different from > CGI::Application::PSGI in two points. > > - support for CGI::Application::Dispatch > - support for func-style access to CGI.pm (overrides %ENV) > > My question is, are you interested in merging CGI::App::Emulate::PSGI > into CGI::App::PSGI? > > The two modules have different APIs so it might be difficult to get > them together, but from end-users' perspective, it would be better not > to have two modules for one purpose uploaded to CPAN. > > Or if you think it is OK to just have two modules on CPAN, I will > upload CGI::App::Emulate::PSGI. > > > For couple of years I have been enjoying using CGI::Application, and > am happy to see my CGI::App-based application start running on Plack. > I plan to switch from mod_fcgid to Plack::Server::Standalone::Prefork > by Wednesday. > > Thank you in advance. Looking forward to hear from you. > > -- > Kazuho Oku >

Mon Dec 14 10:03:08 2009 MARKSTOS [...] cpan.org - Correspondence added

I don't expect to be able to get to this soon myself. I recommend submitting a patch or recruiting help on the CGI::Application mailing list. However, I support the effort and can help with a release once the project progresses further.

Mon Dec 14 10:03:09 2009 The RT System itself - Status changed from 'new' to 'open'

Fri Jan 01 19:04:37 2010 MARKSTOS [...] cpan.org - Taken

Thu Apr 28 18:55:56 2011 tima [...] cpan.org - Correspondence added

RT-Send-CC:

miyagawa [...] gmail.com

Isn't this ticket essentially resolved with CGI::Application::Dispatch::PSGI?

Fri Apr 29 09:20:28 2011 wonko [...] cpan.org - Correspondence added

On Thu Apr 28 18:55:56 2011, TIMA wrote: Show quoted text

> Isn't this ticket essentially resolved with > CGI::Application::Dispatch::PSGI?

Kind of. PSGI is the future of Perl web development so it would be nice if Dispatch supported it natively.

Fri Apr 29 10:43:25 2011 MARKSTOS [...] cpan.org - Correspondence added

Subject:	wish: PSGI/Plack support for CGI::Application::Dispatch
RT-Send-CC:	miyagawa [...] gmail.com

On Thu Apr 28 18:55:56 2011, TIMA wrote: Show quoted text

> Isn't this ticket essentially resolved with > CGI::Application::Dispatch::PSGI?

That module works inefficiently. The whole response is generated as string, then split back apart with regular expressions, and then re-assembled as a 3 part PSGI response. A native solution would generate a PSGI response in the first place. What I've done so far is to rewrite CGI::Application::Dispatch::PSGI to have native support. The current name space owner has given me the blessing to upload my replacement into that name space. My code is here: https://github.com/markstos/CGI--Application--Dispatch/blob/psgi- support/lib/CGI/Application/Dispatch/PSGI.pm If I recall, Tim had suggested the PSGI dispatcher should share more code with the current dispatcher. I paused to take a second look at that and also confirm if I really wanted to switch to use HTTP::Exception here. And that's where the project got stalled. Further feedback on the proposed PSGI.pm replacement is welcome. Mark

Sat Jun 18 05:30:30 2011 james2vegas [...] aim.com - Correspondence added

While version 3.00 of this module with the bundled CGI::Application::Dispatch::PSGI seems to resolve this, the previous un-bundled CGI::Application::Dispatch::PSGI's method of injecting an as_psgi method into the Dispatch namespace required no code changes in Dispatch classes to change the base class, and those Dispatch classes could continue to be used with or without PSGI.

Mon Jun 20 09:50:07 2011 MARKSTOS [...] cpan.org - Correspondence added

On Sat Jun 18 05:30:30 2011, JWRIGHT wrote: Show quoted text

> While version 3.00 of this module with the bundled > CGI::Application::Dispatch::PSGI seems to resolve this, the previous > un-bundled > CGI::Application::Dispatch::PSGI's method of injecting an as_psgi > method into > the Dispatch namespace required no code changes in Dispatch classes to > change > the base class, and those Dispatch classes could continue to be used > with or > without PSGI.

You are welcome to discuss this on-list to see there is a consensus about this, but the design decision was intentional-- the new ::PSGI implementation leaves behind all the Apache1/Apache2 conditional code that's embedded in the old dispatacher. And the new PSGI dispatcher can still be used in all the environments that the old dispatcher worked in.

Mon Jun 20 09:50:10 2011 MARKSTOS [...] cpan.org - Status changed from 'open' to 'stalled'

Thu Aug 30 22:15:52 2012 MARKSTOS [...] cpan.org - Correspondence added

No further feedback. Resolving.

Thu Aug 30 22:15:53 2012 The RT System itself - Status changed from 'stalled' to 'open'

Thu Aug 30 22:15:53 2012 MARKSTOS [...] cpan.org - Status changed from 'open' to 'resolved'