PSGI/Plack updates: Tests, More implementations and Plackup
Tons of progress just on my flight, or while I’m here. Last night I went to the office where Yappo and tokuhirom work, to hack and brainstorm on Plack :)
Specs
Now we’ve got the first spec draft out. It’s mostly a clone of Rack specification, and lots of FAQ document inspired by Python’s WSGI. It still misses the definition of Middleware, which will exactly be the same with WSGI/Rack, and asynchronous support to use start_response callback and writer (I know Python people do not think it was a good idea, but without threads/multitasking environment available universally, i think Perl will still need this) to stream (server push) the content.
Adopted Tests
The reference implementation Plack got a pretty good progress too. Since we have Catalyst::Engine::PSGI, we can reuse Catalyst’s live test suite, or its excellent test framework Catalyst::Test to test a new PSGI implementation. Tuesday morning I spent a few hours to get Plack::Test::Adopt::Catalyst working, which is really a cool hack that allows existent Catalyst::Test based apps unmodified to work with any PSGI implementations, like:
perl -MPlack::Test::Adopt::Catalyst=TestApp -e 'runtests @ARGV' catalyst-based-test.t
You can change the environment variable PLACK_IMPL to test other implementations. I’ve copied over Catalyst-Runtime’s live test suite to Plack and am seeing how the implementation goes like: it mostly works but definitely seeing some failures in some implementations. Maybe a bug of Implementaion, or the adapter Catalyst::Engine::PSGI. Will definitely look into it.
Do you know another web application frameworks that has lots of tests, or test frameworks, and interested in converting those tests to test PSGI implementations?
Plackup
plackup is a command line tool to run PSGI based web application frameworks. It’s inspired by rackup, Python’s paste and Perl’s Sqauatting and is definitely yet another web application framework launcher, but it’s really sexy. With Plack::Loader (auto loading one of Impl::*) and Plack::Adapter (adapter to absorb web application framework API differences). You can say:
catalyst.pl Foo
cd Foo
plackup -a Catalyst Foo
to run the newly created Foo web application with any of Plack implementation. Implementations will be automatically chosen based on some environment variables like MOD_PERL or PLACK_IMPL but you can also pass the command line switch like -i Mojo to specify the implementation. The -a part means which adapter to use but you can write
sub plack_adapter { 'Catalyst' }
in your web application class to avoid specifying -a every time. We have a plan to let web application framework developers to extend plackup to register a new command, so we can share the efforts of this launcher thing, which we already implemented many times in Catalyst, Mojo or Squatting :)
FCGI::EV and Coro implementations
We’ve been experimenting with AnyEvent and Mojo backend to see how callback-based asynchronous web applications should work, and how PSGI async extension should be specified out. Last night we’ve got more additions to this async/multi-tasking backends: FCGI::EV by mala and Coro, which is a straight port of myhttpd script in the Coro distribution. Both should be considered really experimental at this moment, and will be a separate distribution rather than in Plack core ditribution in the near future, but it’s exciting to see how easy it is to write a new web server implementation!
The Future
I just started talking to people who are doing things like the Perl core CGI.pm (Mark Stosberg), mod_perlite (Byrne and Aaron) and Google AppEngine (Brad Fitzpatrick) to see if we can support PSGI there. So in the near future, ideally, someone writes a web app using one of PSGI-supported frameworks like Catalyst, and then can run on ISPs supporting mod_perlite (but not mod_perl because of security reason) or on AppEngine. That’s something we really envy of this Python’s WSGI and Ruby’s Rack. Let’s do this in Perl too!