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

[Ron Savage]

Hi Brett

I'm snipping this email because I expect to pen several replies.

On 06/09/12 03:57, B. Estrade wrote:
> Thank you, Mark. Responses are inlined.

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

Changing the API and keeping a back-compat API means not changing the 
API in the (new) back-compat part of the code.

This is always a difficult decision.

My basic feeling is if people stick with the (new) back-compat API they 
might as well have stuck with the old (back-compat!) API.

So the question is, why not switch to the new API. Perhaps because some 
people want to switch in small steps.

My policy is that if the switch is on, commit to the whole of the new API.

> 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 already use Plack::Middleware::(ContentLength, Session and Static), in 
various situations, when using CGI::Snapp.

You do realize that's possible, right?

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

Absolutely.

My policy is to make available tools for all programmers, not just those 
who adopt the latest mechanism.

After all, there is always going to be a pool of programmers whose work 
environment and/or personality is too conservative to let them be 
amongst the first to switch. They may in fact make that switch years 
after the leaders to. Or, any of us may be employed to support old code.

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

This is a marvellous point.

I've looked a Mojo a number of times, but despite its great cleverness, 
it's major use seems to be smart switching of requests. Likewise, there 
are now quite a new routing-oriented packages available. They all attack 
the same problem, but it's a small part of a whole app. And the classic 
CGI::Application::Dispatch (copied to CGI::Snapp::Dispatch) is a 
beautifully simply way to do that.

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

This is tricky. Why is the env low-resourced? And if it is, what's wrong 
with targeting it with a low-overhead env such as non-Moose?

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

Me neither. For control freaks it obviously gives greater, er, control, 
over parameters and attributes, but that alone does not guarantee great 
apps.

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

This is important.

See:

- Class::Method::Delegate (no dependencies [actually Carp], no bugs)
- Role::Tiny (ditto [actually Exporter], 1 bug)
- Role::Basic (Storable, 3 bugs)
- Moo::Role (various, 2 bugs)
- Moose::Role (ditto, 52 bugs)

But see what Role::Tiny has to say about Role::Basic.

So Moose/Mouse are not actually needed, if smallness is a virtue.

>> - Templating APIs removed from core, for now. We'll get a new templating
>>     API, although the details are still TBD.

Yep.

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

This is important, and probably why moving to PSGI should be considered 
if not done sooner rather than later.

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

In brief, the CGI way has been re-thought and replaced. The end result 
is just request/response of course (what else could it be?), but done 
again with the knowledge of years of experience with CGI.

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

Good idea.

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

Likewise. It's a pity a standard(!) way of doing this with CAP doesn't 
seem to have evolved /with the approval of all/.

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

This statement worries me. Could you please expand.

Also, did you look at CGI::Snapp::Demo::Four::Wrapper, which easily 
wraps CGI::Snapp::Demo::Four. It's specifically a (simple) demo of 
sub-classing.

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

How does this differ from any other class which uses sub-classing? The 
parent method is either completely overridden or called /and/ partially 
overridden. Or am I missing something?

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

There's no doubt they are awkward. I'd argue the underlying CAP 
structure is sound, and just this part need a bug re-think.

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

It'd help if you could expand on this issue.

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

I only use plack (dev) and starman (prod), but I used to use 
Apache(2)::Registry, with CAP. Is that what you're referring to.

Is there something specific which needs to be added?

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

Perhaps you need Mojo after all :-)).


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

On the contrary - many thanx.

We need all ideas to be put out there.......

-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622