Its that time again! Let's review how well things went and try to see if we can make any conclusions that will help us do better next time. Lets start with a look at how well we did against our Questhub goals (http://questhub.io/player/jnap)
Core Unicode Plugin (Complete!)
The stand alone unicode plugin has been successfully merged. There's a few minor differences between the cored version and the stand alone distribution (which continues to be on CPAN for people not ready to upgrade), mostly the fact that the default for the plugin is now to not apply encoding (previously it was defaulted to UTF8). If you use the existing Catalyst Plugin, or start to see unusual encodings on your website, you should review the Upgading notes.
In my mind this is really just the beginning of the UTF8 story for Catalyst, but this is a good first step to both focus the conversation between all the concerned parties as well as ensure people starting new Catalyst based projects get off to the right start. We'll be certainly setting some future goals for this.
Convert existing dispatch types to use Chained Types (Incomplete.)
Although this task has slipped for the past two development cycles, I don't want to mark it as 'stalled' because I feel very sure that this task is the first step toward improving our dispatcher. Right now Catalyst probably has the slowest dispatcher around, and the code complexity we have here makes it very hard to start making things better. Converting all existing dispatch types to use chained is a good first step toward simplifying the code (we'd actually be able to remove a good chunk of older code) and also would give some of he new developers contributing a bit of experience with the dispatcher, which I am sure will help us take on even more complex tasks. So, who is stepping up!
Asynchronous Catalyst (Complete!)
I've seen requests time and again for better support of evented code and long polling in Catalyst, so we released what I consider to be a 'minimal viable implimentation'. The code of course now is very basic, we simple expose some response filehandles (write_fh and io_fh) and let you run from there. Over time we might add more help, but until I see what people actually do here I think doing the smallest useful thing is the right approach. So get out there and show us what you can do!
I'll mark this as complete, although I didn't meet the high goals of having examples using both AnyEvent and IO::Async, two of the more popular event loops. I also wanted a POE example but I couldn't figure out which POE based Plack Handler was considerd the right one to use. Anyone familiar with POE want to help with that? Also, IO::Async looks very, very promising, but there's some test cases that need to be written to improve its Plack handler before I can write good example code, so if anyone wants to help with that (and learn more about evented Perl) give me a shout out.
I realize the docs for this in Catalyst probably suck, for now I am pointing people at the Github example code I have, which I hope is not too bad a way to get you going. Over time I'll try to improve that stuff and turn it into a proper tutorial.
Create a way to allow more control over HTTP PUT/POST, etc (Converted)
Originally the goal here was to experiment and see if a Playframework like approach to Body Parsers might not be useful in Catalyst. Right now the parsing of body request parameters is rather global. Although we have an option (and its a global one) to defer body parameter parsing to when we ask for it, rather than upfront at the start of the request / response cycle, you can't really use this for doing asynchronous reading of the POST body without some hacking. And you don't have
a lot of control at the point were it would be most useful, which I think is in the controller and action. For example, you might have one acion that expects a large XML POST, but right now the default would be to read the entire thing into a temporary file. Wouldn't it be nice if you could just instead stream the POST body filehandle through a XML SAX filter, and just pull out the bits you need? Or if instead for some actions you want to store the POST body right to an Amazon S3 storage bucket?
I think there's a lot to be thought about here, so I will consider the prototype work for this minimally successful, and convert it for the next development cycle into a real task. After talking about this with Matt Trout we came up with the idea of adding a request body filehandle which would give you direct, raw access and let you build custom solutions, including ones that enable easy use of event loops so that you parse your upload chucks aysnchronously. I think this is a good
'minimal viable product' for the goal of improving and making this process more flexible, but of course it won't be the end of the story. Look for some new tasks in the Catalyst Questhub and further discussion when we announce the start of the next development cycle!
Content Negotiation (Stalled)
I'm marking this one as stalled, since I don't think we can do proper RESTful content negotiation with the dispatcher we currently have (or at least I can't see it for now, and will have to ponder it more). On the other hand, maybe all we want is some basic way to dispatch on content request and response types, so that was can do stuff like properly dispatch when the request is a JSON Ajax post... I'm not sure, and could use some community feedback. I do think some of you care about this, since its the quest on Questhub with the most 'thumbs up', but again not enough discussion. Feedback?
Unscheduled Tasks Completed
As always its great to see community members step up with fixes that 'scratched their own itches'! Please shout out if I failed to mention something.
-- Stricter checking of values used on Action attributes. This is a good first step toward inflicting some sanity on how action attributes are validated as well as helping you spot the odd typo.
-- New configuration option to let you abort a chain action at the place were the exception happened, rather than trying to complete the chain, as it does now.
-- Closed a long standing bug which would cause errors in Stats when locale used ',' instead of '.' for decimal separation.`
-- Documentation and test failure fixes.
About the Release Process
So as many of you know we had an initial release that introduced some regressions. Although this was all fixed up pretty promptly (AFAIK, if you are having trouble please shout out) clearly this was undesirable. In the past I have not been a big fan of TRIAL releases, since my experience here is that nobody really tests them out, but perhaps we should go back to doing that..? What do you all think (and please don't say, "Great Idea" if you are never going to download a TRIAL release, but am just hoping someone else does :) )
Upcoming Development Cycle
Next week I'll be floating some ideas about what we are going to focus on for the first half of the summer, but a preview would likely involve work around asynchronous Catalyst, including the POST body filehandle stuff I spoke of, another go at chained dispatch and possible some more code refactoring that the Moose upgrade long ago allowed but was never done. And there is tons of room for people to write example code or work on stuff in the great ecosystem. See you there!
a) What is IO::Async’s Plack handler?
b) I am not going to say TRIAL is a great idea then. :-) But didn’t they at least get you some test results from CPAN Testers? It seems like at least the bungled dependencies in the first couple of 5.9004x releases could have been shaken out that way, even not the bugs in the backcompat shims, which will probably always require testing against existing codebases.
Posted by: Aristotle Pagaltzis | 06/25/2013 at 01:00 PM
a) IOAsync supports an HTTP webserver which you can see over here : https://metacpan.org/release/Net-Async-HTTP-Server and there is a plack handler for this (IOAsync's equiv. to AnyEvent's Twiggy) in that distribution, https://metacpan.org/module/Plack::Handler::Net::Async::HTTP::Server
This evented server has a lot of features, its even http/1.1 support for chunked response.
b) after discussing this on IRC I came to the 'lets make the smallest decision that would have solved some problems' which was to say that no release of catalyst would be allowed without testing on a clean local lib (full build to make sure you catch any and all regressive dependency issues). Going forward I think we will do TRIAL released during a dev cycle when a task was complete in order to let people play with stuff before it is considered stable. So both of those ideas together I think will help.
Posted by: john | 06/25/2013 at 02:10 PM