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