I should also say - thanks for picking this up. I may have been a tad on the grumpy side on my prior mail - new years paging-in-of-everything-after-a-break.
-Rob On 5 January 2016 at 01:27, Cory Benfield <c...@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 -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
