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