Re: Fwd: Collating follow-up on the future of WSGI

--===============8849851596029678407==
Content-Type: multipart/alternative; boundary=089e013a04a8363c11052aabb5e5

--089e013a04a8363c11052aabb5e5
Content-Type: text/plain; charset=UTF-8

On Sun, Jan 31, 2016 at 4:42 PM, PJ Eby <pje-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]> wrote:

> On Thu, Jan 21, 2016 at 12:12 AM, Benoit Chesneau <[email protected]>
> wrote:
> > I am not speaking about websockets. You could use it for SSE, or some
> apps
> > could use the Upgrade header to upgrade from http to their own protocol
> > etc... The only discussion i saw about websockets are about the addition
> of
> > an async api or an external api. I am not describing that. I am speaking
> > about providing a low level abstraction like wsgi.input but adding to it
> the
> > support of output. (I was referring to wsgi.multithread...). This low
> level
> > interface would allow anyone to provide its own implementation(server) or
> > usage (application) still acting as a *gateway* .
>
> It sounds like you may be looking for something like this:
>
> https://gist.github.com/pjeby/62e3892cd75257518eb0
>
> It's a proposed standard protocol for breaking out of WSGI from inside
> of a WSGI application, to access other protocols.  It doesn't deal
> with the details of any particular upgraded protocol, it merely
> provides an "upgrade to specifed protocol" API and a way to safely
> pass it through arbitrary middleware.  The `wsgi.upgrades` environment
> key is used to list available protocols.


The idea of a standardised protocol escape is indeed interesting, though
I'm not so keen on the idea of making triply nested functions a requirement
for something like this.

How would you see this interacting with potential asynchronous
frameworks/reactors? The WebOb example only reacts to events also coming
from within a WebSocket abstraction, but what if I wanted to e.g. send a
message on database save? How would my application manage to trigger the
WebSocket, in another thread or process, to do that?

Andrew

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Jan 31, 2016 at 4:42 PM, PJ Eby <span dir=3D"ltr">&lt;<a href=
=3D"mailto:pje-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]" target=3D"_blank">pje-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On =
Thu, Jan 21, 2016 at 12:12 AM, Benoit Chesneau &lt;<a href=3D"mailto:bchesn=
[email protected]">[email protected]</a>&gt; wrote:<br>
&gt; I am not speaking about websockets. You could use it for SSE, or some =
apps<br>
&gt; could use the Upgrade header to upgrade from http to their own protoco=
l<br>
&gt; etc... The only discussion i saw about websockets are about the additi=
on of<br>
&gt; an async api or an external api. I am not describing that. I am speaki=
ng<br>
&gt; about providing a low level abstraction like wsgi.input but adding to =
it the<br>
&gt; support of output. (I was referring to wsgi.multithread...). This low =
level<br>
&gt; interface would allow anyone to provide its own implementation(server)=
 or<br>
&gt; usage (application) still acting as a *gateway* .<br>
<br>
</span>It sounds like you may be looking for something like this:<br>
<br>
<a href=3D"https://gist.github.com/pjeby/62e3892cd75257518eb0" rel=3D"noref=
errer" target=3D"_blank">https://gist.github.com/pjeby/62e3892cd75257518eb0=
</a><br>
<br>
It&#39;s a proposed standard protocol for breaking out of WSGI from inside<=
br>
of a WSGI application, to access other protocols.=C2=A0 It doesn&#39;t deal=
<br>
with the details of any particular upgraded protocol, it merely<br>
provides an &quot;upgrade to specifed protocol&quot; API and a way to safel=
y<br>
pass it through arbitrary middleware.=C2=A0 The `wsgi.upgrades` environment=
<br>
key is used to list available protocols.</blockquote><div><br></div><div>Th=
e idea of a standardised protocol escape is indeed interesting, though I&#3=
9;m not so keen on the idea of making triply nested functions a requirement=
 for something like this.<br></div><div><br></div><div>How would you see th=
is interacting with potential asynchronous frameworks/reactors? The WebOb e=
xample only reacts to events also coming from within a WebSocket abstractio=
n, but what if I wanted to e.g. send a message on database save? How would =
my application manage to trigger the WebSocket, in another thread or proces=
s, to do that?</div><div><br></div><div>Andrew</div></div></div></div>

--089e013a04a8363c11052aabb5e5--

--===============8849851596029678407==
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

--===============8849851596029678407==--