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

[Mark Stosberg]

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

I'm thinking primarily of these environments:

  - CGI, used in shared hosting accounts where there is persistent option
  - Automated tests, which like CGI, need to load modules each time.

These environments also see non-persistent CGI::App use sometimes:

  - Cron scripts (I use CGI::App for cron scripts for convenience)
  - Interactive command-line scripts (I also use CGI::App for some of
    these which are part of a large website).

I'm not thinking so much in terms hardware. A few years ago I
benchmarked the start-up times of various Perl-based web building tools,
which would apply to the environments above:

 
http://mark.stosberg.com/blog/2008/11/startup-benchmarks-for-mojo-catalyst-titanium-httpengine-and-cgiapplication.html

Since then, hardware has gotten faster, and SSDs are becoming more
common.  Today I benchmark "Mouse" taking .05 seconds to load on my
laptop.  That's price I think is completely reasonable to pay. Without
using a timing tool, the difference in indistinquishable from "instant".

     time -p perl -MMouse -e 1

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

I also see that CGI.pm has over 80 open bugs, while
Plack::Request/Plack::Response appear to have 2 open bugs in the Plack
bug queue that apply to them, with both them appearing to be enhancement
requests.

The number of bug reports a project has seems to often be driven by
popularity. There's also a certain accumulation that comes with age.
The comparison above is misleading in any case, as as the "small" role
solutions have just one module or so in the distribution, so those bugs
are exactly about roles. The Moose bug queue is for the whole Moose
project. Only about 5 or 6 that I see have "role" in the title of the
bug reports.

Also consider that CGI.pm has one person committing fixes for the 80+
bugs (for lack of interest from others, it seems), while the Moose
project appears to have about 8 maintainers.

On it's own, I don't think the general presence of bugs in a bug queue
presents a great concern about the quality of project, although specific
bugs certainly could. Are there specific bugs with Moose or Mouse roles
that you find troubling?

     Mark