On Tue, Jan 19, 2016 at 11:58 PM Robert Collins <robe...@robertcollins.net> wrote:
> On 20 January 2016 at 05:55, Cory Benfield <c...@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
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com