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

Andrew Godwin andrew at aeracode.org
Sun Jan 31 20:57:11 EST 2016

On Sun, Jan 31, 2016 at 4:42 PM, PJ Eby <pje at telecommunity.com> wrote:

> On Thu, Jan 21, 2016 at 12:12 AM, Benoit Chesneau <bchesneau at gmail.com>
> 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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160131/7efa93b0/attachment.html>

More information about the Web-SIG mailing list