3 ms·

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 t

by Wilduck 15y ago

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.

adamtj 15y ago
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.
- 7952 15y ago
  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.

by Wilduck 15y ago

adamtj 15y ago

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.

7952 15y ago
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.