Re: WSGI 2.0 Round 2: requirements and call for interest

--===============0732310526311752424==
Content-Type: multipart/signed; boundary="Apple-Mail=_683F79C8-0225-4BD3-A5E4-E1D38C605603"; protocol="application/pgp-signature"; micalg=pgp-sha256


--Apple-Mail=_683F79C8-0225-4BD3-A5E4-E1D38C605603
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 4 Jan 2016, at 20:27, Cory Benfield <[email protected]> wrote:
>=20
> All,
>=20
> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should =
we do it at all?**
>=20
> 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 =
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.
>=20
> 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=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.
>=20
> 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 without understanding what developers need from a new =
revision of WSGI. This 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 some of the more notable WSGI =
implementers, to ensure that whatever comes out of this SIG is something =
that they would actually use.
>=20
> This WG already had a list of requirements, which are as follows:
>=20
> - 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
>=20
> 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 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 =C3=A0 la Django's channels? Should =
we simply adopt Andrew Godwin=E2=80=99s ASGI draft[1] on which channels =
is based and call *that* WSGI 2.0?
>=20
> 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 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.
>=20
> 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 =
involved in the discussion, but please reach out to others as well.
>=20
> I=E2=80=99d really love to come to the end of 2016 with a solid =
direction for the future of web programming in Python. I=E2=80=99m =
looking forward to working with you all on achieving that.
>=20
> Thanks,
>=20
> Cory
>=20
>=20
> [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


--Apple-Mail=_683F79C8-0225-4BD3-A5E4-E1D38C605603
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJWjPu4AAoJECMItHnTkkoR02YH/2OOGuY0sTtqQGF/j6XClSmN
WYc3huOYjeRvovH2u/szV6ZosX4xp1EYdQywZodWzNkmy1VsmDpG/EiKFk0jJpd0
Tmzh8TOiaFNIKk0nlAE72jGxPudUWd2omujxq+RZAD7egf6G42m03OmRWcWZaHJQ
W5IYKAyuZHN7G6kaHhFgWU+uDJURM+Iq9YjpZ7yR4d+5EKVKQbgSaTAMVg6fujOE
ZAOpNLwRhGanxSYiET8VQsVEz/vcY9G33zo9R1k9L8M1app1o5V8ZtBrhXm74OG4
ZLSyLzMK1xbqEGN5vd7V80tShwD7htW6zPfjecL/8EH1L9Dx8gkMaNAjL3N0ppc=
=FzF9
-----END PGP SIGNATURE-----

--Apple-Mail=_683F79C8-0225-4BD3-A5E4-E1D38C605603--

--===============0732310526311752424==
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

--===============0732310526311752424==--