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

[PJ Eby]

On Sun, Jan 31, 2016 at 8:57 PM, Andrew Godwin  wrote:
> 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.

It's not a requirement; the exact spelling of any handlers or
protocols is up to the escaped-to protocol.  (It could expect a class,
for example, a generator, or an async function.)


> 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?

The overall structure of this approach is that it's a way to do
arbitrary things at the "end" of a standard WSGI request/response
cycle, provided that the special response hasn't been tampered with by
middleware on the way out.  I don't know what you mean by "send a
message on database save" so it's hard to give particulars.  But
basically, the escape mechanism doesn't restrict the escaped-to
protocol in any way, except to the extent that it's affected by the
request side of things.  For example, you can only asynchronously read
the wsgi.input if it hasn't been read at the time the escape message
is received by the origin/gateway server.  Reading request headers via
the extended API might break routing middleware, and so on.  However,
as regards the "response", the escape mechanism should be fully
general, whether the target API is sync or async.
___
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

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

[PJ Eby]

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

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

[Andrew Godwin]

On Sun, Jan 31, 2016 at 4:42 PM, PJ Eby  wrote:

> On Thu, Jan 21, 2016 at 12:12 AM, Benoit Chesneau 
> 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
___
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