Re: Collating follow-up on the future of WSGI

--===============1921702379656107375==
Content-Type: multipart/alternative; boundary=047d7b342d5e173ad10529b7e677

--047d7b342d5e173ad10529b7e677
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 19, 2016 at 11:58 PM Robert Collins <[email protected]>
wrote:

> On 20 January 2016 at 05:55, Cory Benfield <[email protected]> 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 th=
at
> 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=E2=80=99d like to summarise what I believe were =
the big
> take-aways from that discussion to confirm that I=E2=80=99ve understood e=
veryone.
> >
> > I=E2=80=99d 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=E2=80=99s anything we=E2=80=99re m=
issing.
> >
> > The below is formatted in restructured text for clarity, because it=E2=
=80=99s
> quite a lot of information.
> >
> >
> > Concrete Proposals
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >
> > 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 int=
o
> WSGI.
> >
> > Benoit proposed that we could achieve this change by adding a correlato=
r
> 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 pursu=
e
> 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 th=
e
> Link header approach. A simple proposal for how to do this can easily be
> implemented without revising the WSGI specification, and may not even nee=
d
> 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 n=
ot
> 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

--047d7b342d5e173ad10529b7e677
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, Jan 19, 2016 at 11:58 PM Robert Collins &lt;<a href=3D"mailto:robertc@rob=
ertcollins.net">[email protected]</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">On 20 January 2016 at 05:55, Cory Benfield &lt;<a hre=
f=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt; =
wrote:<br>
&gt; All,<br>
&gt;<br>
&gt; Thanks so much for your feedback to my original request for comments o=
n the future of WSGI. You provided a ton of really useful feedback: when pr=
inted out on my printer it ended up at about 50 pages of information that w=
as really engaging reading. I also want to thank you all for keeping the to=
ne of the discussion so positive. On an topic like this one it can get tric=
ky and emotionally charged very easily, and you did a great job of avoiding=
 that problem.<br>
&gt;<br>
&gt; I spent a few hours this morning going over your feedback and trying t=
o extract some common threads. Altogether I believe that most participants =
were mostly in agreement over the direction we should take, with a few outl=
iers in each case. I=E2=80=99d like to summarise what I believe were the bi=
g take-aways from that discussion to confirm that I=E2=80=99ve understood e=
veryone.<br>
&gt;<br>
&gt; I=E2=80=99d also like the members of this SIG to take this opportunity=
 to discuss these proposals more concretely. Rather than expressing our sen=
timents 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 prioritis=
e the work, and whether there=E2=80=99s anything we=E2=80=99re missing.<br>
&gt;<br>
&gt; The below is formatted in restructured text for clarity, because it=E2=
=80=99s quite a lot of information.<br>
&gt;<br>
&gt;<br>
&gt; Concrete Proposals<br>
&gt; =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
&gt;<br>
&gt; WSGI<br>
&gt; ----<br>
&gt;<br>
&gt; Overall, there was strong and fairly unanimous sentiment that WSGI its=
elf 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.<br>
&gt;<br>
&gt; I therefore propose we revise the WSGI specification to WSGI 1.1 and t=
hen consider it &quot;final&quot;. The following points were raised for rev=
ising WSGI.<br>
<br>
Sure.<br>
<br>
&gt; Asynchronous WSGI<br>
&gt; ~~~~~~~~~~~~~~~~~<br>
&gt;<br>
&gt; This was generally regarded as too substantial a change to shoehorn in=
to WSGI.<br>
&gt;<br>
&gt; Benoit proposed that we could achieve this change by adding a correlat=
or 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 asyn=
c protocol in Python.<br>
<br>
Uh, WSGI doesn&#39;t need to be involved in this. Servers can already pass<=
br>
arbitrary objects as write, permitting any correlation they want.=C2=A0 I&#=
39;d<br>
want to see something very specific to consider the impact in terms of<br>
WSGI, or WSGI-NG or whatever we do in future.<br>
<br>
&gt; This proposal is worth highlighting not becuase I think we should purs=
ue it with our revision of WSGI, but because it&#39;s worth considering for=
 any future specification we come up with. Note also that Graham pointed ou=
t that this would require some careful rethinking of reads from ``wsgi.inpu=
t``.<br>
<br>
<br>
<br>
&gt; Server Push<br>
&gt; ~~~~~~~~~~~<br>
&gt;<br>
&gt; We can support HTTP/2 server push using Link headers. This could optio=
nally be supplemented by defining a WSGI extension that provides a callable=
 for doing server push, which would be a mild improvement over the Link hea=
der approach. A simple proposal for how to do this can easily be implemente=
d without revising the WSGI specification, and may not even need to be ensh=
rined 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.<br>
<br>
Since the point of WSGI is interop, we should document the expected<br>
interop fashion for this, whatever it is.<br>
<br>
&gt; Socket Escape Hatch<br>
&gt; ~~~~~~~~~~~~~~~~~~~<br>
&gt;<br>
&gt; Aside from Benoit, server operators were unanimously dismissive of the=
 idea of a socket &#39;escape hatch&#39;. In general it seems like servers =
would not be capable of achieving this. I think, therefore, this idea is un=
workable.<br>
<br>
I thin Benoit is making assumptions about what a &#39;server&#39; is that a=
re<br>
not implied by WSGI - and this is leading to some confusion. Servers<br>
are not necessarily Python processes :).<br><br></blockquote><div><br></div=
><div>not at all. But I made the assumption that the <b>wsgi</b> server mai=
ntained a thread directly or not where the python application is running .=
=C2=A0</div><div><br></div><div>In any case there is some sort of wrapping =
done in the same thread/process where the python application is running. An=
d then nothing stop to give the socket away to the application and tell to =
the server to stop to communicate with it.</div><div><br></div><div><br></d=
iv><div>- benoit</div></div></div>

--047d7b342d5e173ad10529b7e677--

--===============1921702379656107375==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Web-SIG mailing list
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: https://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org

--===============1921702379656107375==--