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

[PJ Eby]

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