[Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Cory Benfield]

> On 4 Jan 2016, at 12:27, Cory Benfield <cory at lukasa.co.uk> wrote:
> 
> All,
> 
> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do it at all?**

Having set up the conversation, I also want to take part in it. So let me outline what I think we need from WSGI 2.

In my opinion, right now WSGI suffers from the following problems:

1. No out-of-the-box support for the concurrent programming techniques that are becoming extremely popular in the Python community and that should be encouraged.
2. No support for WebSockets, HTTP/2 server push, or any kind of generalised “extension” to the HTTP/1.1 request-response model.
3. A lack of an “escape hatch” that allows an application to take responsibility for a connection from the server, thereby ensuring that servers WSGI servers are the bottleneck for innovative and unusual programming techniques.
4. A confused bytes/unicode model that makes it mandatory to mix bytes and unicode in confusing ways at different parts of the stack.
5. A backward-looking design that favours applications doing in-memory buffering of responses over flushing response data to disk as it becomes available.

For this reason, my ideal WSGI 2.0 would be a relatively minor revision of PEP 3333, focusing on addressing these core concerns. PEP 3333 actually contains a great deal of what we already need, but either does not make it mandatory or fails to provide examples of how the tools can be used to solve the problem.

Problem (4) is easily resolved by coming to a consensus position on what fields should be byte strings, what ones should be unicode strings, and then very clearly setting out the rules for handling each side of that interaction.

I’d like to remove the `write` callable and instead **require** that the return value from the application callable be an iterable that produces the body. This should help encourage applications to use generators (or coroutines, as discussed later) to iteratively generate their output. This should help with problem (5) because it will allow us to propagate backpressure through a WSGI server to its application, based on how swiftly the server is able to flush data to the network.

Problem (2) is not actually entirely true: uWSGI has demonstrated that it’s entirely possible to extend WSGI to handle websockets, and such a model could presumably also be used for HTTP/2 server push. I’d like to take the approach of essentially creating ‘blessed’ extensions for websockets and HTTP/2 server push that tie in with the requirement for concurrency in problem (1). These will serve double duty, firstly ensuring that there’s a widely applicable general approach to supporting these features, while also providing a useful example of how WSGI 2 can be extended to support similar HTTP protocol extensions in future.

Fixing problem (3) seems useful to me, but I definitely need feedback from server implementers to see how they feel about becoming essentially dumb TCP proxies for applications in some scenarios.

Fixing problem (1) is the hardest, and for that reason I’ve reached out to a few Python concurrency experts. The best idea I have right now is based on trying to standardise on the ‘awaitable’ type and the ‘async for’ logic from PEP 492 to base WSGI 2 on asynchronous iterators. Essentially, the WSGI 2 callable would return a PEP 493 asynchronous iterable.

I have some concerns about this approach, however. Firstly, I’m nervous about how well this works when called from C (e.g. for servers like uWSGI). Secondly, I want to make sure that it continues to function well with other event loop implementations (e.g. Twisted). For that reason, I’m open to alternative suggestions here. However, I do believe we need to support Python applications running concurrently in an event loop (e.g. asyncio-based or Twisted-based).

I have one further thing that I believe is important: I believe we need to support Python 2.7. It’s my sincere belief that if WSGI 2 is Python 3 only, we will struggle to get anyone to implement it: both servers and application frameworks will wait for people to take up Python 3 before implementing it, and users will not take up Python 3 until servers and application frameworks support WSGI 2.

What do people think of these goals?

Cory

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160104/8f9a8c22/attachment.sig>