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

[Ron Savage]

Hi Mark

On 09/09/12 10:28, Mark Stosberg wrote:
>
>>>> - 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).

OK. Good points.

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

Agreed: .05 sec is nothing.

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

Nope. I did not intend the # of bugs to say anything about the relative 
merits of the modules. It was all about (potential) user education.

IMHO Role::Tiny looks like the best choice.


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