[cgiapp] CGI::Application status update from the maintainer

[Richard Jones]

Hi Mark,

I also use C::A everyday - my main application that I wrote and maintain 
is a C::A. You are of course right that C::A uses some out-of-date 
procedures like the query method. But since C::A first appeared we now 
have newer frameworks like Catalyst, Mojo, and the more recent Dancer 
(also in the process of being rewritten to embrace the Moose API). Given 
that Ron has already forked C::A I wonder if there is any point 
embarking on another?

Accepting that Catalyst is not to everyones taste, and Dancer may not 
yet have the recognition and presence that Catalyst and Mojo/Mojolicious 
have as web frameworks, I'm wondering what advantage a revamped C::A 
under a new name will provide.

One essential item for any web framework is a competent dispatcher, 
something I think compromises Dancer v1 (hopefully addressed in v2), 
essential for an application with a large number of run-modes (or 
equivalents). C::A::Dispatch or a core equivalent is a must IMO. I'm not 
sure if that is what you had in mind with "global dispatching".

Still, best wishes for C::A mark II if you decide to go through with it, 
and looking forward to seeing the draft code later this week :)

On 29/08/2012 04:27, Mark Stosberg wrote:
>
> Hello Everyone.
>
> I'll start with a apology about not being as present as I intended.
> Messages from this list were not coming directly to my Inbox for some
> time, and it took me longer than I wanted to get that addressed.
> Starting today, messages should be going back in my Inbox again, and I
> will attempt be more responsive here.
>
> I'm still alive and well, and use and support CGI::Application every day
> at work. I'm also now the primary maintainer of CGI.pm. While it's only
> a part of the CGI::Application framework, it has substantially more
> lines of code, as well as more bugs and bug traffic. More of my
> maintenance time has been spent maintaining that lately.
>
> I appreciate the fork that Ron Savage recently published, because it's
> good to explore options, and it's easiest to evaluate options if they
> are complete. I also agree with the spirit of it. It's time for the next
> generation of the framework, one that breaks compatibility in some
> places to move the whole forward.
>
> I started writing my own fork over a year ago in hopes of having
> something to share around the time for YAPC 2011. While I needed to put
> that on hold for a while, It's now on the verge of the initial release.
> It was interesting to find Ron's fork which had been developed
> independently and in parallel, to see where we agreed and where we
> differed.
>
> Here are the key points I have mind for the update I'll be publishing
> soon:
>
> - A new name space, to avoid confusion and problems with API changes.
>
> - A "::Compat" addition that allows people to keep using a maximal
>     amount of the old API if they need to. (Including a certain amount of
>     plugins)
>
> - PSGI-native. I'm excited that Perl web frameworks are converging here.
>     We'll be able to take advantage of PSGI "Middleware" that was designed
>     with other frameworks in mind. Many things that were CGI::App plugins
>     before are now better done done as PSGI "Middleware". As a plugin
>     author, you get the benefit of having more users who may be using
>     other frameworks. The difference with CGI::App will be that PSGI will
>     the *only* code path supported.
>
> - Uses Any::Moose / Mouse. I endorse the Moose API and Mouse brings
>     much of that API to lower resource environments, like the CGI
>     environment where CGI::Application has always performed well.
>
>     It's already possible to write a CGI::App subclass based on Moose or
>     Mouse, but like with PSGI, I think it's in our best interest to
>     upgrade to first class support.
>
>     Just as "PSGI Middleware" presents a new opportunity for code re-use,
>     Moose/Mouse "roles" present another alternative to "plugins" that can
>     be shared between frameworks. For example, methods for logging,
>     database access and "config" data are all good candidates to be
>     implemented as roles.
>
> - Templating APIs removed from core, for now. We'll get a new templating
>     API, although the details are still TBD.
>
> - Plans to replace CGI.pm with request and response objects. As the
>     CGI.pm maintainer, I could devote another full post to reasons why I
>     don't to be using it in another 5 or 10 years. Details here are still
>     to be determined as well.
>
>     Immediately we would see the "query()" method replaced with a "req"
>     method to represent a "request" object. HTTP has "requests" and
>     "responses". The idea of a "query object" is a CGI.pm'ism to leave
>     behind.
>
>     About every other Perl framework I've looked at models the response
>     and request this way, and it's time we implemented this sensible
>     design as well.
>
>
> - The popular and small "::Forward()" and "::Redirect()" plugins will
>     be merged into the core.
>
> As part of considering the future of CGI::Application, I did consider
> just dropping it. I maintain it, but lack the emotional attachment of
> being the original author. I stepped back and took a look at it from the
> distance and compared it to alternatives. Outside of the few "details"
> I'd like to change, I find the core of it still offers a unique
> combination of design properties that I think are worth taking forward:
>
>    - I think the flow of the execution stages works very well. I'm talking
>      about "init", "setup", "prerun", "run", "postrun", "teardown", as
>      they are implemented in "new()" and "run()".
>
>    - Lightweight / fast start up time.
>
>    - Simple. Less code to learn, less chance for bugs.
>
>    - Global dispatching. That is, a single central table, rather than
>      storing dispatch details "locally", with each run mode.
>
>    - Ability to scale up. I find CGI::App suitable for large projects as
>      well as small.
>
> There's also a great community of people and plugins around CGI::App as
> well.
>
> I look forward to being conversation with you all more about this. I'll
> set a goal to release the first code-as-draft for my proposal within a
> week, and look forward to your feedback to sculpt it into a releasable
> form.
>
> Thanks,
>
>       Mark
>
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>


-- 
Richard Jones