After a long incubation period, perhaps too long, CGI::Application has been updated today with native PSGI support in the core module as well as PSGI-native dispatcher.
The changes since the last stable versions for each module are included below. You can now find and review on the new MetaCPAN site: http://beta.metacpan.org/recent I've already begun thinking and coding about the next evolution of our framework beyond this. I hope to have drafts to share at or by by YAPC::NA this year, although I won't attending this year due in part to the very recent arrival of a new son. In the meantime, feedback is welcome on these releases. Mark ### 4.50 Thu Jun 16, 2011 [FEATURES] Better PSGI support in the core - run_as_psgi() works like run, but directly returns the expected PSGI response structure - psgi_app() wraps up all the PSGI bits to call and run the application and return a PSGI code ref: $psgi_coderef = WebApp->psgi_app({ ... args to new() ... }); [DOCUMENTATION] - docs for header_props() were improved [INTERNAL] - source control management was moved from darcs to git. Those who prefer darcs are are more familiar with it are advised to try the darcs-git.py wrapper for git. ### 3.00 Jun 16, 2011 [FEATURES] - PSGI support is improved. CGI::Application::Dispatch is now been rewritten and is included in this distribution. It is no longer a wrapper around the older dispatcher, but is completely PSGI-native. Performance should be improved a bit as well. [THINGS THAT MIGHT BREAK YOUR CODE] As part of the significant update to PSGI support, you'll need to update a couple lines of code in your "dispatch.cgi" script if you were using an older version of CGI::Application::Dispatch::PSGI. See the section on "Backwards Compatibility" in that documentation. [INTERNALS] - CGI::Application 4.5 is now required for the newer native PSGI support. - Exceptions in CGI::Application::Dispatch::PSGI are now handled with HTTP::Exception. This in turn depends on HTTP::Status, which is currently in a distribution which depends on HTML::Parser, which depends having a C-compiler available. I don't consider this ideal, as I'd like to be able to support the easy installation of a pure-Perl CGI::Application stack. This could possibly be addressed in the future by removing the false dependency on a C-compiler from HTTP::Status, or we could return to use Exception::Class directly for exception handling. The except format of the default thrown exceptions may change in the future. ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################