On 20 September 2014 19:14, Benoit Chesneau <[email protected]> wrote: > Hi, > > I would prefer to have this work being done transparently. If we do it > rationally it could work imo. > > Anyway before thinking to change the protocol or criticizing it maybe we > could first collect the requirements in HTTP 2 (stream and such) so we can > think about possible implementations. And see what it misses in WSGI. > > I am thinking we could adopt the same path used to decided to go for HTTP > 1.x or HTTP 2 on the client part. Ie keeping WSGI and PEP 3333 for HTTP 1.1 > applications and go for a new interface in HTTP2. But such decision should > be done once we have a clear view of what requires HTTP 2 and how it can be > handled on the python side. > > Thoughts?
+1 on transparency. Agree that before we consider what we need to change we need to set our goals up - thats basically the charter for a PEP: Here is a straw man in prose form: We want to create a clean common API for applications and middleware written in a post HTTP/2 world - where single servers may accept up to all three of HTTP/1.x, HTTP/2 and Websocket connections, and applications and middleware want to be able to take advantage of HTTP/2 and websockets when available, but also degrade gracefully. We also want to ensure that there is a graceful incremental path to adoption of the new API, including Python 2.7 support, and shims to enable existing WSGI apps/middleware/servers to respectively be contained, contain-or-be-contained and contain, things written to this 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. -Rob _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
