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

[Benoit Chesneau]

On Mon, Oct 13, 2014 at 11:52 AM, Robert Collins <robertc at robertcollins.net>
wrote:

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

I answered at the bottom of the thread so to PJE.



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


By which problem we need to solve, I mean we need to identify clearly what
are the problem not solved by the current spec. And see why, and how it is
actually solved in the python world. we need to clearly identify these
issues and make sure we have a comprehensive view of them.


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


I could do that eventually if we are all agree on the process.


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

Chunkedn upload is possible and already handled with Gunicorn. But there is
no standard for that.

For C I would separate it from the rest. This a different discussion and
imo not everything can be achieved at the same time. Maybe we should start
first by fixing them, then go for the next step anyway. So the transition
could be incremental in servers and frameworks and actually fix the current
spec.


For A (And C), i think we should keep the new specification enough
agnostic. Especially since HTTP 2 is not yet completely out.


- benoit

I
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20141013/d80b13bf/attachment.html>