tokuhirom and I have been hacking on reference implementations and test suite for implementors. We added Mojo and AnyEvent based implementations to see how the Input and Error stream and response body API work with asynchronous callback based implementations (Note that these .txt files are notes for discussions, but not actual specs). Yeah, there are things that we really envy in Ruby, Python and even JavaScript: Iterators and built-in types as objects. (Perl does have globref and IO::Handle as a built-in handle objects but they don't duck :/)
Current implementations, as of this writing, pass all tests (great!) but do slurp content in one shot before actually making a request and response with PerlIO, so it'd be much better if we can turn it into actually streamable API. But that's the point of reference implementations: this content slurping is okay in terms of testing PSGI protocol sanity.
Melo, an author of AnyEvent::Mojo jumped in on #http-engine IRC channel and we had a pretty good discussion what needs to be in and out of our core spec and what we should need in 'psgi.async' extension, so WSGI-like start_response callback should be allowed for event-based streaming, or an option not to support $body->foreach($cb) duck type since the event loop loses control, etc.
I'll dump out the current protocol specification as 0.1 draft tonight or tomorrow in PSGI specs repo, which will be as simple as possible, and will continue implementing reference code as well as test suite, then work with real world application frameworks to see what should be improved, etc.
Oh, and now Catalyst has PSGI engine. What does this mean? Catalyst app can run on Mojo daemon or HTTP::ServerSimple or whatever PSGI implementations. Also, we can reuse most of Catalyst unit tests to test a new PSGI implementation.
Groovy, yeah?
Recent Comments