I like the conclusion about using http. This goes against the approach advocated in monolithic frameworks such as django. It would be interesting to see a web framework that separates components and connects them with http.
That's exactly what WSGI does. Well, except for one brilliant improvement: It doesn't pass around raw HTTP, it passes around pre-parsed HTTP data structures. There are three structures: a response code ("200 Ok"), a list of headers, and an iterable that yields the body of the response (or older frameworks write to a filelike object that you can reimplement if necessary). Dealing in pre-parsed (or rather, not-yet-serialized) HTTP makes it much easier to write middleware.
If you really want to plug stuff together with HTTP, there exist HTTP servers that serve wsgi apps, and I'm sure there is a wsgi app somewhere that is an HTTP client. So you plug your framework's wsgi-app (which you didn't write and don't have to worry about) into an HTTP server. Then you point a WsgiHttpProxy at your HTTP server. Plug that WsgiHttpProxy app to your middleware and plug your middleware into another instance of your HTTP server. Rinse and repeat for as many middleware layers as you want. Now everything is HTTP, like you want.
Or, you know, just plug all your middleware together, avoiding parsing, serialization, IPC, context switching and all that crap.
The author isn't arguing that this is a bad idea per se, just that it doesn't actually work that easily.
>> But what I do not believe in is that magical plug that is called “framework independent pluggable application”. I don't know where this idea came from that it might work, but it does not. The idea that you can reused code on top of WSGI to work with Framework 1 and Framework 2 is not working out.
If it's not working out because wsgi.input can't be read twice, then write a middleware that turns it into a StringIO, and write another middleware that rewinds it.
Nothing is going to save you from the fact that you either need to buffer your response, or don't throw an unhandled exception after it's started. Yes it's a problem, but buffering is the only magic that'll help.
If the problem is that middleware authors can't be bothered to implement the whole spec because it's too hard, then submit a patch. I promise you that WSGI is easier to implement than HTTP/1.1 In fact, I would argue that it's as easy as possible. If it were easier, we probably wouldn't be having this discussion, because it wouldn't have been powerful enough to have been adopted.
Or write a middleware container that transforms the WSGI api into something you think is more sane, then implement middleware in thate.
Build the next great thing on top of WSGI, because in the end, the answer is either WSGI, something that's architecturally equivalent, or else each framework has to have its own compression, session, and other libraries. And no answer is going to save you from having to do a little bit of work to put things put together correctly.
I just don't understand why we need a single monolithic product that is at the core of the system. When you use any language specific API you are locking out possibly useful tools.
The overhead of asking each component to use HTTP is an acceptable price to pay for native compatibility with the Internet.
