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://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
