On 04:40 pm, armin.ronac...@active-4.com wrote:
Hi,
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.
At PyCon, there was some discussion about what changes could be made to
the WSGI spec to extend it to support asynchronous applications. I
probably have some notes, and I think I even sent them to the list at
the time. Perhaps those with an interest in async WSGI could take a
look at those and weigh in on the merits of the conclusions reached.
A number of other people also posted to a thread which covered more of
the WSGI ideas discussed at PyCon. The top of that thread is here:
http://www.mail-archive.com/web-sig@python.org/msg02569.html
I posted an example of what an asynchronous WSGI application might look
like here:
http://www.mail-archive.com/web-sig@python.org/msg02582.html
(it looks like I forgot to do anything relating to start_response there
- I don't remember if this was intentional or not).
I think there was also some talk about how it would be desirable to
support asynchronous response header generation.
Jean-Paul
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
