3 ms·

To be honest I never understood why wsgi conflated buffered and streaming modes in one API. Having two separate specialized sets of API makes much more sense.

slurgfest 14y ago
There isn't any notion of 'buffered mode' in WSGI. It is just left up to the app to buffer as needed before yielding. Middleware and servers are not supposed to perform buffering. So I don't see how the two are conflated. How am I misunderstanding you?
- the_mitsuhiko 14y ago
  > There isn't any notion of 'buffered mode' in WSGI. It is just left up to the app to buffer as needed before yielding. Middleware and servers are not supposed to perform buffering. So I don't see how the two are conflated. How am I misunderstanding you? The problem is that you would have to support streaming because you don't know what the inner WSGI application is doing. Our stuff does not work on top of WSGI because of that. At the end of the day it is implemented as a WSGI application but it only uses WSGI for talking to the server.
  - slurgfest 14y ago
    I don't think I have any criticism for your approach on your project. I was trying to comment on the idea that WSGI somehow conflates buffered mode with streaming mode. How is that even possible when WSGI does not even have a notion of buffered mode? If you want your app or even your framework to buffer, you can just do that in the app layer. I can't see that the server interface should have additional moving parts just to do what is cleanly doable in the app layer. I can only imagine this being a disappointment if someone wanted to use WSGI middleware to carry out buffering. But if (edit: internal) WSGI compatibility is not a high priority, then why would you want to use WSGI middleware for this (generally pretty messy)? Do it in your framework or in your app. So I do not understand the complaint about the 'conflation' of buffering and streaming. I think it is appropriate to leave the buffering decision in the app layer. And it is also reasonable to use WSGI as just a way to talk to a server (what else is it really for? Obviously not to offer a big fat servlet API...) If you want to do separate buffering and streaming APIs in your app layer then that could be a smart way to reduce complexity but I don't see why this is some sort of complaint about WSGI.
chubot 14y ago
Yeah all the warts in WSGI are basically because of streaming. They should have been 2 APIs. Nobody likes start_response, and I think that was because of streaming. Although I suppose you could still return a 3-tuple (status, headers, body) and still have the body be iterable, so maybe I'm wrong.

slurgfest 14y ago

There isn't any notion of 'buffered mode' in WSGI. It is just left up to the app to buffer as needed before yielding. Middleware and servers are not supposed to perform buffering. So I don't see how the two are conflated. How am I misunderstanding you?

the_mitsuhiko 14y ago
> There isn't any notion of 'buffered mode' in WSGI. It is just left up to the app to buffer as needed before yielding. Middleware and servers are not supposed to perform buffering. So I don't see how the two are conflated. How am I misunderstanding you? The problem is that you would have to support streaming because you don't know what the inner WSGI application is doing. Our stuff does not work on top of WSGI because of that. At the end of the day it is implemented as a WSGI application but it only uses WSGI for talking to the server.
- slurgfest 14y ago
  I don't think I have any criticism for your approach on your project. I was trying to comment on the idea that WSGI somehow conflates buffered mode with streaming mode. How is that even possible when WSGI does not even have a notion of buffered mode? If you want your app or even your framework to buffer, you can just do that in the app layer. I can't see that the server interface should have additional moving parts just to do what is cleanly doable in the app layer. I can only imagine this being a disappointment if someone wanted to use WSGI middleware to carry out buffering. But if (edit: internal) WSGI compatibility is not a high priority, then why would you want to use WSGI middleware for this (generally pretty messy)? Do it in your framework or in your app. So I do not understand the complaint about the 'conflation' of buffering and streaming. I think it is appropriate to leave the buffering decision in the app layer. And it is also reasonable to use WSGI as just a way to talk to a server (what else is it really for? Obviously not to offer a big fat servlet API...) If you want to do separate buffering and streaming APIs in your app layer then that could be a smart way to reduce complexity but I don't see why this is some sort of complaint about WSGI.

chubot 14y ago

Yeah all the warts in WSGI are basically because of streaming. They should have been 2 APIs. Nobody likes start_response, and I think that was because of streaming. Although I suppose you could still return a 3-tuple (status, headers, body) and still have the body be iterable, so maybe I'm wrong.