[erlang-questions] Misultin EOL

Benoit Chesneau <>
Sat Feb 18 12:33:42 CET 2012


On Sat, Feb 18, 2012 at 12:30 PM, José Valim <> wrote:
>> There are many servers and many libs/frameworks handling the spec.
>> Only the code quality, the technical differences and features distinct
>> them.  I guess somethng like that could be defined in Erlang with a
>> lib reference to test the validaty and validate servers and libs
>> behaviour (just like wsgiref in Python). Same exist with Rack in ruby
>> world and probably in other language.
>
>
> 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
> endpoint 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.
>
> 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.
>
> 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.
>
> 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.

well at least in wsgi, nothing stop you to stream your content. Or
even use sendfile. But right that's something a spec should take in
consideration. In gunicorn for example I added the socket to the WSGI
environ.

- benoît



More information about the erlang-questions mailing list