[Web-SIG] WSGI and async Servers
armin.ronacher at active-4.com
Thu Sep 17 18:40:20 CEST 2009
For this topic I would love to remember everybody that the web is
currently changing and will even more change in the future which will
probably also mean that a lot of what we're doing currently might not be
common practise in the near future.
WSGI is currently not doing to well for asyncronous applications, so
people claim. I don't know where this is coming from, probably because
everybody still thinks our data storages are traditional databases. But
we really have to wake up from that idea and start at least
*considering* asynchronous designs when it comes to WSGI.
Tornado appeared recently and from a technical perspective, it's a step
backwards. It's not supporting all of HTTP and it's clearly not
supporting WSGI in any way beyond the very basics. But the interesting
point is, that this does not matter for many applications. Even for an
application that was never designed to be non-blocking that just
recently dropped MySQL for most of the data, Tornado is a huge
performance improvement (personal experience).
Why would it be good to encourage async applications on top of WSGI?
Because people would otherwise come up with their own implementations
that are incompatible to each other. Maybe that should not go into WSGI
but a AWSGI or whatever, but I'm pretty sure we should at least consider
it and ask people that use asynchronous applications/servers what the
issues with WSGI are.
More information about the Web-SIG