[Web-SIG] Collating follow-up on the future of WSGI

[Benoit Chesneau]

On Tue, Jan 19, 2016 at 11:58 PM Robert Collins <robertc at robertcollins.net>
wrote:

> On 20 January 2016 at 05:55, Cory Benfield <cory at lukasa.co.uk> wrote:
> > All,
> >
> > Thanks so much for your feedback to my original request for comments on
> the future of WSGI. You provided a ton of really useful feedback: when
> printed out on my printer it ended up at about 50 pages of information that
> was really engaging reading. I also want to thank you all for keeping the
> tone of the discussion so positive. On an topic like this one it can get
> tricky and emotionally charged very easily, and you did a great job of
> avoiding that problem.
> >
> > I spent a few hours this morning going over your feedback and trying to
> extract some common threads. Altogether I believe that most participants
> were mostly in agreement over the direction we should take, with a few
> outliers in each case. I’d like to summarise what I believe were the big
> take-aways from that discussion to confirm that I’ve understood everyone.
> >
> > I’d also like the members of this SIG to take this opportunity to
> discuss these proposals more concretely. Rather than expressing our
> sentiments about WSGI and its future more generally, I want people to
> critique and offer opinions on *these specific proposals*. The goal here is
> to get an understanding of whether these are worth doing, how we need to
> prioritise the work, and whether there’s anything we’re missing.
> >
> > The below is formatted in restructured text for clarity, because it’s
> quite a lot of information.
> >
> >
> > Concrete Proposals
> > ==================
> >
> > WSGI
> > ----
> >
> > Overall, there was strong and fairly unanimous sentiment that WSGI
> itself should more or less be left alone. Minor adjustments would be
> valuable, and we should pursue them, but the contributors do not believe
> that making a substantial revision to WSGI would be adviseable.
> >
> > I therefore propose we revise the WSGI specification to WSGI 1.1 and
> then consider it "final". The following points were raised for revising
> WSGI.
>
> Sure.
>
> > Asynchronous WSGI
> > ~~~~~~~~~~~~~~~~~
> >
> > This was generally regarded as too substantial a change to shoehorn into
> WSGI.
> >
> > Benoit proposed that we could achieve this change by adding a correlator
> to WSGI. This would allow servers to associate a given call to ``write()``
> with a specific request/response (most useful in HTTP/2 where this could
> correspond to a stream ID). This would then allow WSGI to transition to a
> purely callback-based model that could in principle cohabitate with an
> async protocol in Python.
>
> Uh, WSGI doesn't need to be involved in this. Servers can already pass
> arbitrary objects as write, permitting any correlation they want.  I'd
> want to see something very specific to consider the impact in terms of
> WSGI, or WSGI-NG or whatever we do in future.
>
> > This proposal is worth highlighting not becuase I think we should pursue
> it with our revision of WSGI, but because it's worth considering for any
> future specification we come up with. Note also that Graham pointed out
> that this would require some careful rethinking of reads from
> ``wsgi.input``.
>
>
>
> > Server Push
> > ~~~~~~~~~~~
> >
> > We can support HTTP/2 server push using Link headers. This could
> optionally be supplemented by defining a WSGI extension that provides a
> callable for doing server push, which would be a mild improvement over the
> Link header approach. A simple proposal for how to do this can easily be
> implemented without revising the WSGI specification, and may not even need
> to be enshrined in a PEP. However, if we revise the WSGI PEP we may want to
> provide a small section that indicates how to add these headers.
>
> Since the point of WSGI is interop, we should document the expected
> interop fashion for this, whatever it is.
>
> > Socket Escape Hatch
> > ~~~~~~~~~~~~~~~~~~~
> >
> > Aside from Benoit, server operators were unanimously dismissive of the
> idea of a socket 'escape hatch'. In general it seems like servers would not
> be capable of achieving this. I think, therefore, this idea is unworkable.
>
> I thin Benoit is making assumptions about what a 'server' is that are
> not implied by WSGI - and this is leading to some confusion. Servers
> are not necessarily Python processes :).
>
>
not at all. But I made the assumption that the *wsgi* server maintained a
thread directly or not where the python application is running .

In any case there is some sort of wrapping done in the same thread/process
where the python application is running. And then nothing stop to give the
socket away to the application and tell to the server to stop to
communicate with it.


- benoit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160119/9dda1779/attachment.html>