21–30 of 63 posts
start_response/yield may not be the absolute best API for this, I haven'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's not actually too great.
When you write your own copy of WSGI to change how some words are spelled, you don't gain much, but you lose the whole WSGI community. This seems rather pointless to me.
WSGI is a low-level protocol that provides a minimal interface to an HTTP Server ala CGI. It is purposefully not an application-level HTTP toolkit. For example, a WSGI component takes an input stream and returns an iterable which could yield output chunks... of perhaps in infinite data stream. These edge cases are sometimes very important and why the interface is designed as it is: inconvenient as it may be for simple apps.
Earlier quoted context omitted.
> In my view, the problems with WSGI are that it has an unpythonic API (see: start_response and environ), Why do you find `start_response` unpythonic?
The problems with start_response have been discussed at length in Web-SIG. As far as I know, they're planning to remove it from the spec in WSGI 2.0 (whenever that's published).
> We could remove start_response and the writer that it implies.
I searched for `wsgi start_response issues` and didn't get anything useful. Care to point out what's the fuss with start_response and why it's unpythonic?
The point of WSGI is not to be a good abstraction of HTTP. As an app author, you aren't supposed to care. The advantage of WSGI is that it's standard, and everything uses it. That means you can use any web framework with any web server, and it will all Just Work. When you write your own copy of WSGI to change how some words are spelled, you don't gain much, but you lose the whole WSGI community. This seems rather poi…
Or if you are really keen on working low level, you use a nice wsgi library viz. werkzeug.
Also, there's no clearly defined format for middleware added by keys - the included middleware just adds plain old keys as it pleases.
But more generally, I don't really see the purpose of this. WSGI is obviously not ideal (thanks to start_response and CGI environment variables), but it's also quite firmly in place in the Python world. Not to mention that it would take the Pump library quite a while to catch up to Werkzeug or WebOb in terms of having all the necessary HTTP primitives implemented. (Multipart parsing, anyone?) Unless the server makers get on board, Pump is pretty much just an added layer of complexity on top of WSGI. Instead of "server | WSGI | WSGI library | framework", you have "server | WSGI | Pump adapter | Pump library | frameworK".
Earlier quoted context omitted.
# WSGI def app(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) yield 'Hello World\n' # Rack app = proc do |env| [ 200, {'Content-Type' => 'text/plain'}, "a" ] end WSGI is the Rack for Python. In fact, WSGI predates Rack, and Rack is WSGI inspired.
They are both predated by: public class App extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain"); response.getWriter().println("Hello world"); } }
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't be this simple.
One basic reason that WSGI can't be as simple as just returning a dictionary is that you don'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't know the response size beforehand?
Pump is basically doing what lots of other things already do, except without quite understanding HTTP quite as well.
Earlier quoted context omitted.
# Pump def app(request): return { "status": 200, "headers": {"content_type": "text/plain"}, "body": "Hello World"}
You sure have put effort and the project looks good, but I am missing the purpose. If the problem it tries to solve is parsing environ to form response objects, or providing vanilla middlewares, that problem is very well solved by a wsgi library. Have you looked at werkzeug?
I understand your point that web developers don't necessarily work with WSGI on a day-to-day basis. But if you look at the Ruby web community, Rack middlewares are much more prevalent than WSGI middlewares. Application developers (as opposed to framework developers) often add functionality as a Rack middleware, so that it can be reused in different applications, even using different frameworks. Why isn't that happening with Python as much? In the Python world, instead of writing even simple middlewares to for basic functionality like https://github.com/adeel/pump/blob/master/pump/middleware/pa... or https://github.com/adeel/pump/blob/master/pump/middleware/co..., every framework ends up reimplementing it. I believe this is because the WSGI API is ugly and not as easy to understand as it could be (just look at the average WSGI middleware).