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

[Amber "Hawkie" Brown]

> On 4 Jan 2016, at 20: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?**
> 
> It’s a new year, and that means it’s time for another attempt to get WSGI 2.0 off the ground. Many of you may remember that we attempted to do this last year with Rob Collins leading the charge, but unfortunately personal commitments made it impossible for Rob to keep pushing that attempt forward.
> 
> Since then, the need for a revision of WSGI has become even more apparent. Casual discussion on the web has indicated that application developers are uncomfortable with the limitations of WSGI. These limitations are providing an incentive for both application developers and server developers to take an end-run around WSGI in an attempt to get a framework that is more suitable for the modern web. A great example of the result of WSGI’s deficiencies is Andrew Godwin’s channels work[0] for Django, which represents a paradigm shift in application development that takes it far away from what WSGI is today.
> 
> For this reason, I think we need to try again to get WSGI 2.0 off the ground. But I don’t believe we can do this without getting broad consensus from the developer community that a revision to WSGI is needed, and without understanding what developers need from a new revision of WSGI. This should take into account the prior discussions we’d had on this thread: however, I’m also going to actively solicit feedback from some of the more notable WSGI implementers, to ensure that whatever comes out of this SIG is something that they would actually use.
> 
> This WG already had a list of requirements, which are as follows:
> 
> - Support servers speaking HTTP/1.x, HTTP/2 and Websockets (potentially all on a single port).
> - Support graceful degradation for applications that can use HTTP/2 but still support HTTP/1.x requests.
> - Graceful incremental adoption path - no upgrade-all-components requirement baked into the design.
> - Support Python 2.7 and 3.x (where x is not yet discussed)
> - Support the existing ecosystem of containers (such as mod_wsgi) with the new API. We want a clean, fast and approachable API, and we want to ensure that its no less friendly to work with than WSGI, for all that it will expose much more functionality.
> - Apps need to be able to tell what protocol is in use, and what optional features are available. For instance, HTTP/2 PUSH PROMISE is an optional feature that can be disabled by clients. Websockets needs to expose a socket like object, and so on.
> - Support websockets
> - Support HTTP/2
> - Support HTTP/1.x (which may be just 'point at PEP-3333’.)
> - Continue to support lightweight shims being built on top such as https://github.com/Pylons/webob/blob/master/webob/request.py
> 
> I believe that all of these requirements are up for grabs, and subject to change and consensus discussion. In this thread, then, I’d like to hear from people about these requirements and others. What do you believe WSGI 2.0 should do? Just as importantly, what do you believe it should not do? What prior art should we take into account? Should we bother revising WSGI at all, or should we let the wider application ecosystem pursue its own solutions à la Django's channels? Should we simply adopt Andrew Godwin’s ASGI draft[1] on which channels is based and call *that* WSGI 2.0?
> 
> Right now I want this to be very open. I’d like people to come up with a broad statement listing what they believe should and should not be present in WSGI. This first stage of the work is very general: I just want to get a feeling for what the community believes is important. Once we’re done with that, if the consensus is that this work is worth pursuing, I’ll come up with an initial draft that we can start making concrete changes to.
> 
> In the short term, I’m going to keep this consultation open for **at least two weeks**: that is, I will not start working on an initial draft PEP until at least the **18th of January**. If you believe there are application or server developers that should be involved in this discussion, please reach out to them and point them to this list. I personally have CC’d some people that I believe need to be involved in the discussion, but please reach out to others as well.
> 
> I’d really love to come to the end of 2016 with a solid direction for the future of web programming in Python. I’m looking forward to working with you all on achieving that.
> 
> Thanks,
> 
> Cory
> 
> 
> [0]: https://channels.readthedocs.org/en/latest/
> [1]: https://channels.readthedocs.org/en/latest/asgi.html

Hi all! Due to some dubious life choices, I've decided to take part in this discussion!

I have very much a vested interest in async making sense in a new WSGI, and personally would go so far to say that a WSGI revision that does not include asynchronous support is a WSGI revision not worth having. But, I am also not sure if it should be a WSGI revision -- as Graham has mentioned, such a radical revision that (I personally) believe is required is likely to go poorly if we call it WSGI, because now we have all this "WSGI" stuff that doesn't actually speak WSGI 2.

I'm looking forward to future developments, and hopefully we can finally unify the synchronous and asynchronous worlds of Python web programming.

- Amber Brown

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