3 ms·

That was quite a rabbit hole, but a good read nonetheless. I was pretty surprised at all the criticisms that Pump received yesterday (http://news.ycombinator.c

That was quite a rabbit hole, but a good read nonetheless. I was pretty surprised at all the criticisms that Pump received yesterday (http://news.ycombinator.com/item?id=2810373 http://news.ycombinator.com/item?id=2810373). The general response was defensive and critical just because it was trying to replace WSGI. However, it would seem that WSGI isn't perfect for all applications and indeed there is a place for Pump. My question is: how can we resume encouraging people to contribute? Quite honestly, if I had posted that thread and received the response it got, I would be utterly discouraged from contributing to the community in the future.

sirn 15y ago
But the thing is the problem Pump solves, is already solved by all WSGI wrappers at application level: Werkzeug and WebOb. I don't think it's really worth to have another standard just to solve something that has been solved at the application level (and may led to even more confusions in the future.) Armin Ronacher (who also is the author of Werkzeug) did designed something similar, called Webapi[1] and as he mentioned in the article, it's not a very good idea. [1]: https://github.com/mitsuhiko/super-secret-wsgi-replacement https://github.com/mitsuhiko/super-secret-wsgi-replacement
- endlessvoid94 15y ago
  That is a good point. However, the thing that's attractive to me about Pump is how exceedingly simple it is. A lot of things (like Django) try to do a LOT. The complexity of frameworks like WebOb seem to be growing, and that's a turnoff. I did take a look at Werkzeug and it's one that is definitely awesome. But I think there's a false expectation that choice is bad. There's nothing wrong with Pump. It's another choice, and the response from the community was "WE ALREADY HAVE THIS" instead of "good job". There's nothing wrong with Pump (at first glance). And instead of giving it a chance, the reaction is "no thanks". And that's sad.
  - kingkilr 15y ago
    The thing wrong with it is it presents itself as a replacement to WSGI without solving all of the problems that WSGI goes (or any new ones, AFAICT). And as a result, no, I won't use it in replacement of a standard for which I have tools aplenty.
  - rdtsc 15y ago
    > the thing that's attractive to me about Pump is how exceedingly simple it is The problem with that is that "your simple" != "everyone else's simple". Maybe my "simple" is to have the ability to yield chunks of data as it gets generated using chunked transfer. It is a simple thing, WSGI can handle but Pump can't. Pump is trying to replace WSGI but WSGI is a standard, if it tries to replace a standard API it has to prove that it can do all the things WSGI can do, so WSGI can be kicked to the side and everyone can switch to Pump. So to summarize, it is ok if Pump just claimed to be a simple HTTP interface but as soon as it claims to be a better, less complex WSGI, then it starts to play the "standard" game and it show how the author doesn't really understand what WSGI is and how it got to be that way.
    - pyninja 15y ago
      > Maybe my "simple" is to have the ability to yield chunks of data as it gets generated using chunked transfer. I'm curious, have you ever actually had to do this? Even Rails only just got this feature in 3.1 (http://weblog.rubyonrails.org/2011/4/18/why-http-streaming http://weblog.rubyonrails.org/2011/4/18/why-http-streaming).
      - rdtsc 15y ago
        Yes I had to do this for an interactive media site.
adamtj 15y ago
WSGI is _not_ a framework. It's a gateway interface, like CGI. Django is a web application framework. You don't (usually) write apps using a raw gateway interface like WSGI or CGI. You write web applications in a framework like Django or Pump. The framework then needs to work with the web server -- but how? To be portable and useful, a framework it should support CGI, SCGI, Fast-CGI, ISAPI, HTTP, etc. That lots of work to do for every single framework. Big ones and little ones all need to support all those interfaces, and you know they won't. That's the whole point of WSGI: to be one single abstraction to bind all web servers to all frameworks. If you want to write a framework, WSGI sets the bar pretty dang low. It supports pretty much everything you need to do HTTP without too many awkward quirks. You don't need to worry about how to implement a fast-cgi->nginx adapter. You just make your framework talk WSGI and plug it into existing nginx->fast-cgi and fast-cgi->wsgi libraries. Done. WSGI was carefully designed to be as simple as possible, but no simpler. It is simple, but powerful and flexible. It's possible to write powerful composable middleware that works with any webserver and any framework, because middleware is just a WSGI app that wraps a WSGI app. Middleware can transparently add sessions, caching, compression, chunking, etc, that don't need to be tightly coupled to the framework or the webserver. So, just like WSGI can bind all webservers to all frameworks, any middleware can insert itself between any framework/webserver pair (I'm sure there are exceptions, of course). The framework shouldn't have to screw around with chunked encodings or compression. WSGI's design allows one good library to easily do that work regardless of the rest of your stack. This article spoke about how awkward send_request() is. What it does is make it trivial for middleware to read, add, and modify headers without having to parse HTTP. Suppose you want to write a javascript obfuscator. One way to do that is to write some middleware that detects Content-Type="text/javascript" and obfuscates the response. Because of the way send_request() works, you detect javascript by looking at a variable, not writing an HTTP parser. Also, if you write that middleware for Django, it'll work unchanged when you get fed up and switch frameworks. The whole write() vs yield vs return thing can is awkward, but it makes it easier to write a wsgi adapter for older cgi-based frameworks that respond via sys.stdout.write(). Only framework, middleware and gateway authors have to care about WSGI. If a framework author is complaining about WSGI, he or she almost definitely don't understand where WSGI came from or what problem it's really solving. WSGI is minimal, composable, and elegant, even considering that it's backwards compatible with older frameworks. If everything supports WSGI, then everything can just be plugged into everything else without much screwing around. Composability and loose coupling are very powerful, especially at the levels of the stack where WSGI lives.
nikcub 15y ago
it was still a good contribution because it prompted this discussion, this blog post and it might lead to something new again

sirn 15y ago

But the thing is the problem Pump solves, is already solved by all WSGI wrappers at application level: Werkzeug and WebOb. I don't think it's really worth to have another standard just to solve something that has been solved at the application level (and may led to even more confusions in the future.) Armin Ronacher (who also is the author of Werkzeug) did designed something similar, called Webapi[1] and as he mentioned in the article, it's not a very good idea. [1]: https://github.com/mitsuhiko/super-secret-wsgi-replacement https://github.com/mitsuhiko/super-secret-wsgi-replacement

endlessvoid94 15y ago
That is a good point. However, the thing that's attractive to me about Pump is how exceedingly simple it is. A lot of things (like Django) try to do a LOT. The complexity of frameworks like WebOb seem to be growing, and that's a turnoff. I did take a look at Werkzeug and it's one that is definitely awesome. But I think there's a false expectation that choice is bad. There's nothing wrong with Pump. It's another choice, and the response from the community was "WE ALREADY HAVE THIS" instead of "good job". There's nothing wrong with Pump (at first glance). And instead of giving it a chance, the reaction is "no thanks". And that's sad.
- kingkilr 15y ago
  The thing wrong with it is it presents itself as a replacement to WSGI without solving all of the problems that WSGI goes (or any new ones, AFAICT). And as a result, no, I won't use it in replacement of a standard for which I have tools aplenty.
- rdtsc 15y ago
  > the thing that's attractive to me about Pump is how exceedingly simple it is The problem with that is that "your simple" != "everyone else's simple". Maybe my "simple" is to have the ability to yield chunks of data as it gets generated using chunked transfer. It is a simple thing, WSGI can handle but Pump can't. Pump is trying to replace WSGI but WSGI is a standard, if it tries to replace a standard API it has to prove that it can do all the things WSGI can do, so WSGI can be kicked to the side and everyone can switch to Pump. So to summarize, it is ok if Pump just claimed to be a simple HTTP interface but as soon as it claims to be a better, less complex WSGI, then it starts to play the "standard" game and it show how the author doesn't really understand what WSGI is and how it got to be that way.
  - pyninja 15y ago
    > Maybe my "simple" is to have the ability to yield chunks of data as it gets generated using chunked transfer. I'm curious, have you ever actually had to do this? Even Rails only just got this feature in 3.1 (http://weblog.rubyonrails.org/2011/4/18/why-http-streaming http://weblog.rubyonrails.org/2011/4/18/why-http-streaming).
    - rdtsc 15y ago
      Yes I had to do this for an interactive media site.

adamtj 15y ago

WSGI is _not_ a framework. It's a gateway interface, like CGI. Django is a web application framework. You don't (usually) write apps using a raw gateway interface like WSGI or CGI. You write web applications in a framework like Django or Pump. The framework then needs to work with the web server -- but how? To be portable and useful, a framework it should support CGI, SCGI, Fast-CGI, ISAPI, HTTP, etc. That lots of work to do for every single framework. Big ones and little ones all need to support all those interfaces, and you know they won't. That's the whole point of WSGI: to be one single abstraction to bind all web servers to all frameworks. If you want to write a framework, WSGI sets the bar pretty dang low. It supports pretty much everything you need to do HTTP without too many awkward quirks. You don't need to worry about how to implement a fast-cgi->nginx adapter. You just make your framework talk WSGI and plug it into existing nginx->fast-cgi and fast-cgi->wsgi libraries. Done. WSGI was carefully designed to be as simple as possible, but no simpler. It is simple, but powerful and flexible. It's possible to write powerful composable middleware that works with any webserver and any framework, because middleware is just a WSGI app that wraps a WSGI app. Middleware can transparently add sessions, caching, compression, chunking, etc, that don't need to be tightly coupled to the framework or the webserver. So, just like WSGI can bind all webservers to all frameworks, any middleware can insert itself between any framework/webserver pair (I'm sure there are exceptions, of course). The framework shouldn't have to screw around with chunked encodings or compression. WSGI's design allows one good library to easily do that work regardless of the rest of your stack. This article spoke about how awkward send_request() is. What it does is make it trivial for middleware to read, add, and modify headers without having to parse HTTP. Suppose you want to write a javascript obfuscator. One way to do that is to write some middleware that detects Content-Type="text/javascript" and obfuscates the response. Because of the way send_request() works, you detect javascript by looking at a variable, not writing an HTTP parser. Also, if you write that middleware for Django, it'll work unchanged when you get fed up and switch frameworks. The whole write() vs yield vs return thing can is awkward, but it makes it easier to write a wsgi adapter for older cgi-based frameworks that respond via sys.stdout.write(). Only framework, middleware and gateway authors have to care about WSGI. If a framework author is complaining about WSGI, he or she almost definitely don't understand where WSGI came from or what problem it's really solving. WSGI is minimal, composable, and elegant, even considering that it's backwards compatible with older frameworks. If everything supports WSGI, then everything can just be plugged into everything else without much screwing around. Composability and loose coupling are very powerful, especially at the levels of the stack where WSGI lives.

nikcub 15y ago

it was still a good contribution because it prompted this discussion, this blog post and it might lead to something new again