<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are many servers and many libs/frameworks handling the spec.<br>
Only the code quality, the technical differences and features distinct<br>
them.  I guess somethng like that could be defined in Erlang with a<br>
lib reference to test the validaty and validate servers and libs<br>
behaviour (just like wsgiref in Python). Same exist with Rack in ruby<br>
world and probably in other language.<br></blockquote><div><br></div><div>I agree that a common interface is desired but we should steer far away from Rack and WSGI. Rack in particular was designed with the concept of <b>endpoint</b> that is the entity responsible for calculating the response and send it back after the response is generated. This means that async and streaming the response as you get it are very hard to achieve because the whole ecosystem and the specs were not designed to handle such scenarios.</div>

<div><br></div><div>Something that gets this right though is servlet API from Java with the concept of generators, filters and etc. Streaming works fine as you can, at any point, push data into the socket and filters/generators are wrapped by this API.</div>

<div><br></div><div>Every time I see a Erlang or a Node.js framework based on top of Rack/WSGI a part of me dies because the ability of streaming and asynchronously pushing stuff down the socket is one of the best features you would have in such frameworks.</div>

<div><br></div><div>PS: I am one of the core members of Rails by far the biggest framework that relies on Rack. We tried to add streaming on Rails 3.1 which made very clear all the shortcomings of the Rack API. We will eventually work on a Rack 2.0 that is more inspired by the Servlet API.</div>

</div>