[Web-SIG] Draft 2: WSGI Response Upgrade Bridging

[Robert Collins]

On 13 October 2014 17:12, Benoit Chesneau <bchesneau at gmail.com> wrote:
>
...
>
>
> OK,
>
> So I should probably know you, but I can't recollect right now what you do
> or write.

Its not clear to me who you were replying to.

If Graham - Graham is the mod_wsgi maintainer, which I'm sure you've
heard of - he, like you is one of the actors we need engaged and
behind this effort. And PJE was the original WSGI maintainer :).

> Anyway I find it really disturbing the way you're actually acting
> and try to push your ideas based on private feedback coming from unknown or
> choosing who should be a reference. That certainly not the right way to have
> all actors on the table. Because if we go for a new WSGI spec, you certainly
> want it. And I am speaking as one of these actors.

As I said when folk talked about going private in the first thread on
this, I'm willing to discuss anything publically or privately - I
can't tell folk where they will be comfortable discussing things. But
I'm going to do *my* work on this in public, because I think that is
essential to get broad consensus.

> In my opinion, if we want to go further we should first define what are the
> problem we want to solve, and then get the feedback from all the actors
> around:

I think I've been fairly clear about the problem *I* want to solve.

"""
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.
"""

> - framweorks authors

I reached out to a number of such authors directly. I encourage you to
do the same.

> - libraries author

Ditto and

> - server authors

Ditto :).

> If you don't have all actors around and majors are missing, there is
> probably no point to continue. I do think the idea of having a repository to
> collect it with people arbitrating the discussions on them on the mailing is
> a good way to go further. Now I think we are still missing of a clear
> definition of the problem. This is from what we should start instead of
> starting by giving our philosophy on how the problem should be solved.

Here's my definition of some of the problems:
A - there is no common spec equivalent to WSGI that permits writing
server side code that takes advantage of HTTP/2. There's *a* http/2
server out there which one can write code for, but that code is either
specific to that servers plumbing, or plain WSGI and misses the HTTP/2
goodness.
B - WSGI has some oddness and overheads due in large part to the
situation it was aiming to fix (which it broadly did) that perhaps we
can now come together to fix.
C - Support for chunked uploads, comet, bosh and websockets is
effectively impossible within WSGI - one ends up writing server
specific code, and being tied to a single server - even though
multiple servers support (some of) those things. This defeats the
point of WSGI IMNSHO: its not that WSGI is broken or anything, its
just that we're once again writing all our generic middleware in
server-specific fashions. Because the world has moved on and we
haven't.

I think A and C are crucial if we want to re-instate a lingua franca
for the current web, in Python. I'd like to address B, because we can.

-Rob

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