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

[Benoit Chesneau]

what do you need asynchronous? And how the current callback system can't
fit the needs of an an asynchronous lib? what do you miss actually?

Note that http and http2 are not asynchronous. Imo we need a new WSGI spec
and a Messaging gateway spec. but these are orthogonal discussions imo.

- benoit

On Wed, 6 Jan 2016 at 12:52, Amber "Hawkie" Brown <hawkowl at atleastfornow.net>
wrote:

>
> > 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
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> https://mail.python.org/mailman/options/web-sig/bchesneau%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160106/dd801da7/attachment-0001.html>