<story><title>Show HN: Pump, a dead simple Pythonic abstraction of HTTP.</title><url>http://adeel.github.com/pump/</url><text></text></story><parent_chain></parent_chain><comment><author>justin_vanw</author><text>&quot;What WSGI should have been.&quot;&lt;p&gt;Well, not at all.  Pump is what werkzeug, webob, and other more friendly wrappers on WSGI already are.  Basically pointless duplication of work, without understanding why WSGI can&apos;t be this simple.&lt;p&gt;One basic reason that WSGI can&apos;t be as simple as just returning a dictionary is that you don&apos;t necessarily want the entire body of your response pre-computed before starting to return data to the client.  What about long running connections?  What if you want to return the head of the response immediately, so the client can start pulling css and js while you compute the body of the response?  What if you want to do chunked encoding to support long polling connections, or responses where you don&apos;t know the response size beforehand?&lt;p&gt;Pump is basically doing what lots of other things already do, except without quite understanding HTTP quite as well.</text></comment>
<story><title>Show HN: Pump, a dead simple Pythonic abstraction of HTTP.</title><url>http://adeel.github.com/pump/</url><text></text></story><parent_chain></parent_chain><comment><author>collint</author><text>The Rack style API is nice for the simplicity. I &amp;#60;3 it.&lt;p&gt;The Rack style api is NOT a great representation of the HTTP protocol. Specifically anything with a streaming or chunked response.&lt;p&gt;start_response/yield may not be the absolute best API for this, I haven&apos;t thought to much about that. But if you go look into what was done in Rails 3.1 for chunked responses you may realize it&apos;s not actually too great.</text></comment>