[btilly]

It is far easier to take a fundamentally-streaming stack and layer conventional request-response on top as a special case than it is to take a conventional request-response stack and layer a stream on top of that.

You're asking the wrong question. The right question is how much of a problem is it for your conventional request-response app to be built on top of something that really wants the streaming aspects exposed. And the answer is quite a bit.

For example, there are significant performance benefits to putting caching proxies in front of applications. But whether that is a reverse proxy sitting at your hosting facility or a distributed proxy that you're getting from Akamai, they introduce a strong assumption that you're not going to stream content through them.

So stuff you're going to likely want to do anyways at some point pushes you to want to separate request-response from streaming. And if are going to make that choice anyways, it makes little sense to add any complexity to your life at all to try and keep those together.

[jerf]

You don't want to do it because it's hard. If it wasn't hard, you'd do it more. It shouldn't be hard. Our collective reaction to websockets shouldn't be flipping out at how cool they are, it should be "it's about time you gave me back the things you took away".

Of course you want a strong page framework built on top, but the point really is it's easier to start with the streams underneath and build something that limits the streams to the request-response cycle than to go the other way, not that request-response isn't an important simplification that is frequently useful or that it shouldn't be very strong itself.

But you shouldn't go and write it into your WSGI standard or hard-wire your shiny new web server to insist on what are morally CGI pages, and break down crying if somebody wants to stream a little bit.