Re: WSGI 2.0 Round 2: requirements and call for interest

Cory Benfield <[email protected]> Mon, 4 Jan 2016 15:30:31 +0000
Newsgroups	gmane.comp.python.web
Message-ID	<[email protected]>
> On 4 Jan 2016, at 15:08, Armin Ronacher <armin.ronacher-GGlT2RywCWtWk0Htik3J/[email protected]> wrote:
> 
> I honestly do not think that you can have it both ways: a WSGI specification and a raw socket.  Maybe we reached the point where WSGI should just be deprecated and frameworks themselves will fill the gap. We would only specify a data exchange layer so that frameworks can interoperate in some way or another.

This is one of the bits of feedback I expected we’d get, and it’s one we really do need to consider. It’s possible that the time for WSGI is coming to a close.

However, I’d like to try not to give up as a first step. =)

Your core question seems to be: “why do we need a spec that specifies concurrency?” I think this is reasonable. One way out might be to take the route of ASGI[0], which essentially uses a message broker to act as the interface between server and application. This lets applications handle their own concurrency without needing to co-ordinate with the server. From there the spec doesn’t need to handle concurrency, as the application and server are in separate processes.

However, if the application and server run together (as with WSGI today), I don’t think we can get out of needing to talk about concurrency, because *not* talking about it essentially forces the application to assume that each request/response cycle runs in a new process and that it cannot share memory or resources. That’s what we have at the moment, and using something like asyncio or Twisted in such an environment is very tricky and essentially requires that you run on top a server that also uses them (see Hendrix or Klein).

Let’s step back for a moment and consider the most simple case: one request, one response, both sent across WSGI as a complete entity. Could we not specify that the application callable has to return an object that is analogous to a future/promise/Deferred: essentially, an object that can be waited on until the response is ready. In that situation, a WSGI server could repeatedly call the application callable and then wait until any of the future/promise/Deferreds is ready, then send that data back in the response. This would allow the application to use its own concurrency model. Setting aside whether it’s a good model (it’s not), do you agree that it would work?

If it would, I think it’s reasonable to consider whether we can come up with a different, sufficiently-general approach to this problem, potentially based on that kind of approach.

Cory


[0]: https://channels.readthedocs.org/en/latest/asgi.html

_______________________________________________
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
signature.asc (application/pgp-signature, 801 B)