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

[Robert Collins]

So, as Graham said, I think calling it 2.0 is a bit of an issue -
HTTP/2.0 and WSGI 2.0 are not synonymous, given the diverse
requirements we have.



On 5 January 2016 at 01: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.

Whats the goal? The goal I had when I started was to enable a
portable-across-servers websockets + HTTP/2 capability in the Python
world. A PEP is one route to doing that. Just putting some code
together and offering it to many projects is another way forward. WSGI
is sufficiently lightweight in definition that there is no need to
include anyone else's implementation. I (sadly) suspect that that is
still important to folk, particularly folk like Graham who are doing
cross-process things already (and have been for years).

Things that I think are not a goal:
 - being able to handle any future IETF protocol through this thing.
If its a ratified standard that doesn't look like HTTP{1,2} or
websockets, there's no guarantee that it will fit the model we come up
with now. That said, there are WSGI adapters to do SMTP, and that
certainly doesn't look like HTTP :).
 - being directly compatible with WSGI
 - being an exact fit for any one, or even most Python web frameworks today.

I think that WSGI got many things right - thats why so many things
support it - but identifying which of its attributes is a factor for
success, and which isn't is really hard: we're a decade on, more or
less, and the ecosystem is a lot bigger. w.r.t. ASGI, it sounds like
mongrel2 just in earlier days. Its a nifty way to build things, but I
think its missing a fairly important thing: its not conceptually
simple any more.

I think what we would benefit from is:
 - engagement from mod_wsgi, the nginx uwsgi folk, and perhaps a
smattering of the active people from
http://wsgi.readthedocs.org/en/latest/servers.html
 - likewise on the application side: we need a Django person engaged
with this - I reached out for one at the start of the last initiative
but didn't manage to hook anyone, flask folk being interested would be
good etc.


I think WSGI got the following things really right:
 - it was widely advertised (europython talks, etc etc)
 - it *is* a defined standard
 - framework authors can write good-enough adapters to their own stuff
in a day, more or less.
 - servers can support it in a day, more or less [assuming they
already have HTTP support themselves]
 - it doesn't bake in any assumptions that are really hard to satisfy
 - there is a reference implementation that works

What we actually need, concretely, is a proposal. Something that can
be considered and thought about, and worked through by the many
interested parties.

As far as the requirements are concerned - that list above is actually
pretty small. We could easily balloon it up by (for instance),
insisting on async support (the prior discussion around this concluded
that asyncio's whole set of interactions will be different, so that
should be a different PEP, though they may be able to share some
common data structures. If we try to futureproof, leaving deliberate
ways to do something undefined in a compatible fashion, we're
guaranteed to make things much much more complex. For instance - raw
access to the socket was mentioned in your other mail?! Gosh no, thats
simply impossible in a number of servers today, and it would make
writing an adapter for this new thing really very hard. Even
websockets sockets are not sockets in the sense that most folk think
about sockets.

Having spent the last year running off and tackling a bunch of other
things, I'd like to propose the following way forward:

1 - draft a PEP for WSGI-NG that handles:
  - HTTP/1.x, HTTP/2, websockets
  - wrapping a WSGI app
  - wrapping an NG app for a WSGI server
  - retains the basic-types-only interface, for cross-process friendliness
  - no presumption of shared state in the specification. (WSGI is
ambiguous about whether environ is shared in a stack of decorators or
not, and its led to hilarity before)
  - strong - and I mean strong - isolation between
servers-that-own-the-fd and any contained application. All three
protocol's we're talking about have strict framing layers, and only
server authors have any business dealing with the plumbing.
  - use coroutines or generators systematically

2 - socialise that with the various interested groups. Ask if they
love it or hate it. Ask if supporting it is straightforward or
requires fugly stuff. Ask if they would benefit if they adopted it.

3 - iterate.

Or to put it another way - I think the opinions are well known, what
we're missing right now is a careful detailed creation put together
that brings in the needed expertise to craft something useful.

On the asyncio / await etc side: I leave this up to the author.
Thunking to WSGI from awaitable's would be tedious and thread-heavy I
suspect. Obviously it can be done. AFAIK right now there is no mass
move to asyncio from the server frameworks around: we're not going to
solve the problems they have today with WSGI (e.g. the server-specific
websockets requirements) by  making standardisation be predicated on
moving something like Django to a new server core. I recall attempts
to move other big frameworks around years ago now, taking a long long
time.... I think the question of 'how can we enable interop of HTTP
applications in asyncio' is best handled by a dedicated effort
analogous to WSGI but in that programming model.

-Rob


-- 
Robert Collins <rbtcollins at hpe.com>
Distinguished Technologist
HP Converged Cloud