Re: WSGI 2.0 Round 2: requirements and call for interest
Benoit Chesneau <[email protected]> Wed, 06 Jan 2016 12:12:53 +0000
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <CAJNb-9r4SW3q=qjXJBbvP_svda2fmoRBh5cNkPTnfPSYyjf8gQ@mail.gmail.com> |
--===============8682260954668369688== Content-Type: multipart/alternative; boundary=047d7b342d5eb2214c0528a94692 --047d7b342d5eb2214c0528a94692 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 <[email protected]= t> wrote: > > > On 4 Jan 2016, at 20:27, Cory Benfield <[email protected]> wrote: > > > > All, > > > > **TL;DR: What do you believe WSGI 2.0 should and should not do? Should > we do it at all?** > > > > It=E2=80=99s a new year, and that means it=E2=80=99s time for another a= ttempt 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 an= d > 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 th= e > result of WSGI=E2=80=99s deficiencies is Andrew Godwin=E2=80=99s 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=E2=80=99t believe we can do this without getting broad = consensus > from the developer community that a revision to WSGI is needed, and witho= ut > understanding what developers need from a new revision of WSGI. This shou= ld > take into account the prior discussions we=E2=80=99d had on this thread: = however, > I=E2=80=99m 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=E2=80=99.) > > - 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=E2=80=99d lik= e 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 WSG= I > at all, or should we let the wider application ecosystem pursue its own > solutions =C3=A0 la Django's channels? Should we simply adopt Andrew Godw= in=E2=80=99s > ASGI draft[1] on which channels is based and call *that* WSGI 2.0? > > > > Right now I want this to be very open. I=E2=80=99d like people to come = up with a > broad statement listing what they believe should and should not be presen= t > 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=E2=80=99re = done with > that, if the consensus is that this work is worth pursuing, I=E2=80=99ll = come up > with an initial draft that we can start making concrete changes to. > > > > In the short term, I=E2=80=99m 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=E2=80=99d some people that I believe need to be involv= ed in the > discussion, but please reach out to others as well. > > > > I=E2=80=99d really love to come to the end of 2016 with a solid directi= on for > the future of web programming in Python. I=E2=80=99m looking forward to w= orking > 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" stuf= f > 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 > [email protected] > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > https://mail.python.org/mailman/options/web-sig/bchesneau%40gmail.com > --047d7b342d5eb2214c0528a94692 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div style=3D"white-space:pre-wrap">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?<br><br>Note that http and http2 are not as= ynchronous. Imo we need a new WSGI spec and a Messaging gateway spec. but t= hese are orthogonal discussions imo.<br><br>- benoit</div><br><div class=3D= "gmail_quote"><div dir=3D"ltr">On Wed, 6 Jan 2016 at 12:52, Amber "Haw= kie" Brown <<a href=3D"mailto:[email protected]">hawkowl@at= leastfornow.net</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> > On 4 Jan 2016, at 20:27, Cory Benfield <<a href=3D"mailto:cory@luka= sa.co.uk" target=3D"_blank">[email protected]</a>> wrote:<br> ><br> > All,<br> ><br> > **TL;DR: What do you believe WSGI 2.0 should and should not do? Should= we do it at all?**<br> ><br> > It=E2=80=99s a new year, and that means it=E2=80=99s time for another = attempt to get WSGI 2.0 off the ground. Many of you may remember that we at= tempted to do this last year with Rob Collins leading the charge, but unfor= tunately personal commitments made it impossible for Rob to keep pushing th= at attempt forward.<br> ><br> > Since then, the need for a revision of WSGI has become even more appar= ent. Casual discussion on the web has indicated that application developers= are uncomfortable with the limitations of WSGI. These limitations are prov= iding 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=E2=80=99= s deficiencies is Andrew Godwin=E2=80=99s channels work[0] for Django, whic= h represents a paradigm shift in application development that takes it far = away from what WSGI is today.<br> ><br> > For this reason, I think we need to try again to get WSGI 2.0 off the = ground. But I don=E2=80=99t believe we can do this without getting broad co= nsensus from the developer community that a revision to WSGI is needed, and= without understanding what developers need from a new revision of WSGI. Th= is should take into account the prior discussions we=E2=80=99d had on this = thread: however, I=E2=80=99m also going to actively solicit feedback from s= ome of the more notable WSGI implementers, to ensure that whatever comes ou= t of this SIG is something that they would actually use.<br> ><br> > This WG already had a list of requirements, which are as follows:<br> ><br> > - Support servers speaking HTTP/1.x, HTTP/2 and Websockets (potentiall= y all on a single port).<br> > - Support graceful degradation for applications that can use HTTP/2 bu= t still support HTTP/1.x requests.<br> > - Graceful incremental adoption path - no upgrade-all-components requi= rement baked into the design.<br> > - Support Python 2.7 and 3.x (where x is not yet discussed)<br> > - 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 en= sure that its no less friendly to work with than WSGI, for all that it will= expose much more functionality.<br> > - Apps need to be able to tell what protocol is in use, and what optio= nal features are available. For instance, HTTP/2 PUSH PROMISE is an optiona= l feature that can be disabled by clients. Websockets needs to expose a soc= ket like object, and so on.<br> > - Support websockets<br> > - Support HTTP/2<br> > - Support HTTP/1.x (which may be just 'point at PEP-3333=E2=80=99.= )<br> > - Continue to support lightweight shims being built on top such as <a = href=3D"https://github.com/Pylons/webob/blob/master/webob/request.py" rel= =3D"noreferrer" target=3D"_blank">https://github.com/Pylons/webob/blob/mast= er/webob/request.py</a><br> ><br> > I believe that all of these requirements are up for grabs, and subject= to change and consensus discussion. In this thread, then, I=E2=80=99d like= to hear from people about these requirements and others. What do you belie= ve WSGI 2.0 should do? Just as importantly, what do you believe it should n= ot do? What prior art should we take into account? Should we bother revisin= g WSGI at all, or should we let the wider application ecosystem pursue its = own solutions =C3=A0 la Django's channels? Should we simply adopt Andre= w Godwin=E2=80=99s ASGI draft[1] on which channels is based and call *that*= WSGI 2.0?<br> ><br> > Right now I want this to be very open. I=E2=80=99d 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 wa= nt to get a feeling for what the community believes is important. Once we= =E2=80=99re done with that, if the consensus is that this work is worth pur= suing, I=E2=80=99ll come up with an initial draft that we can start making = concrete changes to.<br> ><br> > In the short term, I=E2=80=99m going to keep this consultation open fo= r **at least two weeks**: that is, I will not start working on an initial d= raft PEP until at least the **18th of January**. If you believe there are a= pplication 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= =E2=80=99d some people that I believe need to be involved in the discussion= , but please reach out to others as well.<br> ><br> > I=E2=80=99d really love to come to the end of 2016 with a solid direct= ion for the future of web programming in Python. I=E2=80=99m looking forwar= d to working with you all on achieving that.<br> ><br> > Thanks,<br> ><br> > Cory<br> ><br> ><br> > [0]: <a href=3D"https://channels.readthedocs.org/en/latest/" rel=3D"no= referrer" target=3D"_blank">https://channels.readthedocs.org/en/latest/</a>= <br> > [1]: <a href=3D"https://channels.readthedocs.org/en/latest/asgi.html" = rel=3D"noreferrer" target=3D"_blank">https://channels.readthedocs.org/en/la= test/asgi.html</a><br> <br> Hi all! Due to some dubious life choices, I've decided to take part in = this discussion!<br> <br> 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 inclu= de 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" st= uff that doesn't actually speak WSGI 2.<br> <br> I'm looking forward to future developments, and hopefully we can finall= y unify the synchronous and asynchronous worlds of Python web programming.<= br> <br> - Amber Brown<br> <br> _______________________________________________<br> Web-SIG mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]<= /a><br> Web SIG: <a href=3D"http://www.python.org/sigs/web-sig" rel=3D"noreferrer" = target=3D"_blank">http://www.python.org/sigs/web-sig</a><br> Unsubscribe: <a href=3D"https://mail.python.org/mailman/options/web-sig/bch= esneau%40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://mail.pytho= n.org/mailman/options/web-sig/bchesneau%40gmail.com</a><br> </blockquote></div> --047d7b342d5eb2214c0528a94692-- --===============8682260954668369688== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org --===============8682260954668369688==--