4 ms·

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 ha

by 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.

by sirn 15y ago

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.