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

[B. Estrade]

Thank you, Mark. Responses are inlined.
 
On Tue, Aug 28, 2012 at 11:27:04PM -0400, 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.

It strikes me that CAP is more of a "way" or standard than any
particular implementation, even though I think it could certainly be
standardized or have that one true reference implementation.

> 
> 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)

Or maybe just do something like how perl5 turns on new version based
features (e.g., use CGI::Application q/1.2.3/;).

> 
> - 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.

Nice.

I would like to warn that traditional persistent environments will
continue to remain relevant, and I think it's a mistake to discount
this.

Additionally, from what I have seen from the other frameworks, nothing
solves anything in principle beyond what CAP does. Some make it easier
to define runmodes or to set up dispatching, but you still need to
properly create a proper MVC separation and set of supporting modules.
It's the same amount of work no matter what you use.

> 
> - 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.

I am not sure what this buys anyone, to be frank. I know that using
these object layering might incite some sort of religious war.
Ultimately, this decision is clearly in the hands of those who do the
work.  I have my reservations about moving away from Perlish idioms
and towards the oop flavors of the week. Any core might be well served
by avoiding any sort of meta object sugar over the long haul. 

I think my overall point is that CAP and what it provides is timeless.
The pendulum swings both ways, and it would be nice to see CAP focus
on improving its strengths and not trying to do what the other kids
might be doing.

> 
>    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.

I think I am not really clear on what change in perspective means. Is
it truly a semantic change or is it just a different name? I am
somewhat familiar with some of the other new fangled frameworks, but
not well enough to know what the difference is between this
request/response versus query objects.

> 
> 
> - The popular and small "::Forward()" and "::Redirect()" plugins will
>    be merged into the core.

It would be really nice to merge in some bare bones Authentication and
Authorization support - maybe ever by more fully developing CAP's lifecycle.

> 
> 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 am a recent addition to this community, and prefer CAP well over the
other alternatives.

> 
> 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.

Here are some items I would like to see addressed.

1. scalability - it is unnecessarily awkward to have more than 2
levels of subclassing currently. 

Direct subclass of CAP uses cgi_init; child of subclass uses setup;
anything else must call SUPER::setup.

2. a more fully developed lifecycle model - similar to the one that
Apache itself uses.  In particular, it would be really helpful to have
explicit  phases for state (e.g., Session munging), authentication,
and authorization.  I imagine those 3 in particular to be extremely
helpful for building things like role based access control or single
sign-on into your application.

3. a more fully developed plugin/event system; I think this goes along
with #2 (i.e., a few more hooks), but in addition to this I have
always thought it would be useful to have some sort of mechanism
through which plugins might be able to query one another.  A good
example (and actually the main motivation for #2 and #3) are the CAP
Authorization and Authentication plugins.  The short list of troubles
I have had with using these two are:

 * when used together, Authorization is called before Authentication,
 making it awkward to handle authorization errors of unauthenticated
 guests (or maybe Authz assumes an authenticated session);

 * default behavior of Authz is to query directly the Authorization
 plugin instance for a username; this works fine in that situation,
 but there is no clear way for plugin A to make information available
 to plugin B;

That's just an example. I think that these improvements would go a
long way to encouraging the timeless benefits that you've outlined
about CAP above.

4. more flexibility with the query object...err response object; I've
run into some hoops to jump through when I wanted to use CGI::Simple
and be able to upload capabilities on or off in a sub class.

5. persistence - I would like to say that I'd like to learn more about CAP and
the ecosystem in persistent environments. It's my impression that
there are some corner cases or funny issues with it. I do not claim
this is true, but I think that we can all agree that while persistent
environments such as mod_perl are considered old fashioned, I think
that they will prove remain relevant amist the tide of alternatives and 
"middleware" laden configurations. For me, the ultimate goal would be
to use CAP to create a responsive and consistent daemon type
application as served by Apache, defined strictly through things like runmodes, 
plugins, etc. Is PSGI the path to this? Maybe, maybe not.

6*. the last mile - in application frameworks, I am unsure of any that
take the finite state machine model to its logical max. This thought
may be way out there, but defining things like runmodes only takes you
so far. Going a step further, perhaps done through more feature dispatching
or routing, it'd be really nice to be able to define the application
runmodes in terms of a transition function (e.g., current runmode,
input, resulting runmode). In otherwords, support defining an
application to the fullest extent possible though some sort of runmode
dispatch table annotations.

*(forgive me this one is "out there", and I still have not sat down to
figure out what such a capability would look like or value it would
actually add)

Brett

> 
> 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/                 ##
> ##                                                            ##
> ################################################################
> 

-- 
Register Now for cPanel Conference
Oct 8-10, 2012, Houston, Texas
http://conference.cpanel.net/