Plack 0.99* (and 1.0) milestones

I am pleased to announce that i've just shipped Plack 0.99_01 to CPAN, the first dev release towards Plack 1.0.

What's New?

There's been lots of refactorings, renames and changes but first of all, this 1.0 release should be 99.9% transparent to the end users, and they don't need to change anything wrt how to use Plack. I carefully added backward compatibility code here and there when I rename things.

What this release would affect most are developers: middleware developers, server developers and framework developers. For the first two, I think I've communicated very well, and I'm already working with them on github, to keep their code up to date with the changes, while the changes required are so minimal, or even better, in most cases, none.

Plack is now officially PSGI "toolkit"

There's been confusions about what Plack is: Is it a middleware library, a mini framework or a web server. Though there's a google bomb campaign to link Plack with Perl Web Server (thanks everyone! :D) Plack is not technically a web server:

Is Plack a framework? - No. It's a toolkit for frameworks
Is Plack a web server? - Not technically, but has lots of adapters and handlers for web servers. It also bundles the reference pure perl web server: HTTP::Server::PSGI
Is Plack a middleware library? - Yes, but something more than that.

So, PSGI is an interface and Plack is an API and tools around it, that you can actually run your server or application on. I hope it clarifies things more.

Plack::Request changes

(If you're a lucky framework developer that doesn't use Plack::Request like CGI::Application, Mojo, Dancer or Catalyst, then you can skip the entire section :))

The biggest change that would impact framework developers is that Plack::Request is now in core distribution. It is a good utility for middleware developers and framework developers, but it has a nature of a port from HTTP::Engine::Request which is a port from Catalyst::Request. That means some methods do not make much sense, or it has something applications or frameworks should do, rather than Plack should do.

Plack::Request internals have been rewritten and refactored a lot, so it's now designed to work in middleware components safely, by caching the parsed parameters as well as the post body in the env buffer or a temporary file, and you can instantiate Plack::Request as many times as you want in the middleware chain and it just works.

There are small incompatibilities: Some methods, such as parameters, path, cookies still work but behave now a bit differently, but for good purpose. It is to remove the oddness of parameters(), fixes the code/doc mismatch in the path handling and says good bye to undocumented weird Cookie serializations, originating from CGI.pm. We discussed these things on #plack IRC channel and it seemed everyone agreed that this change is a good change. (Or, whoever opposed to the changes were just silent :))

I apologize in advance that if these incompatible changes cause any problem or unexpected behavior on your application, and am happy to help if you have questions etc.

More changes before 1.0

I can't promise anything but I'm expecting 2 weeks or more before making Plack 1.0 release, the changes planned before that happens would include:

Dechunk HTTP requests and HTTP::Server::PSGI uses the temp buffer to implement psgi.input (being worked on topic/chunked-input branch)
Some PSGI extension to allow non-blocking read from psgi.input and/or raw socket access, to make things like WebSocket possible
charset decoding support in Plack::Request and Response
Rename Plack::Server::* to their own namespaces

Keep questions coming in the comment or on the IRC!