2009/9/18 Armin Ronacher <armin.ronac...@active-4.com>: > 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.
Let me clearly state that I am not against the concept of asynchronous or event driven systems. In my 20+ years of coding I have done more work in the area of event driven systems than in other areas. My work on Apache/mod_wsgi and mod_python before that are merely hobbies in comparison. My bread and butter has been distributed messaging and publish/subscribe systems based on event driven systems running across large networks of hosts and sites for building complex real time applications. What I simply don't want is for the asynchronous issue to stop us again from sorting out the synchronous WSGI specification. Let us just deal with it later rather than it once again becoming a distraction. FWIW, one thing I am against with event driven systems is those which are poorly implemented. I also get annoyed when people make claims for event driven systems that are somewhat tenuous. Although event driven systems can be good for some things, they have to be used properly. Trying to adapt them in ways they shouldn't can cause subtle problems. Often people pushing event driven systems either don't understand the potential problems, or want to gloss over them in some way. Trying to bolt a synchronous WSGI directly on top an event driven systems, particular in a multi process web server is a good example for potential problems as I have blogged about in the past in relation to nginx/mod_wsgi. You will get the same sort of potential issues with Tornado depending on how they try to use it in conjunction with WSGI. If we ever actually finalise synchronous WSGI and I can get some measure of closure on Apache/mod_wsgi in as much as it being as feature complete as worth pursuing, then an event driven based web serving mechanism for Python applications and associated static files is certainly an area I am interested in looking at. I already have my own ideas for how I would go about doing it and it isn't like what people are doing now. With the sort of mix of technologies I have in mind I see no reason why it wouldn't perform better than the systems being pushed in the Python world at present. So, hurry up and work out this synchronous stuff and maybe I can get back on to the event driven system, which frankly I find more interesting anyway. :-) Graham _______________________________________________ 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
