>> >> Sure. You probably would want to escape from wsgi for the couple of urls >> in your application that really need to be async, while writing the >> traditional parts traditionally. >> > > This is where I think Brubeck would really shine. It works entirely around > gevent's natural async mechanism while keeping all the code looking sync, > just as gevent promises. > > Pairing up uWSGI with gevent forces code to look like this: > http://projects.unbit.it/uwsgi/wiki/Gevent - Which means the user is > explicitly calling yield to context switch with WSGI. This means you > actually have both implicit and explicit context switching. One is often > confusing enough. >
Argh, no, this is not required, it is only a (crazy, as the title) example on how to maintain a WSGI style approach. You can always send raw data to the communication socket (even if it is considered blasphemous by the WSGI crew.... :P) via the uwsgi api. Let's clarify things as this is taking to form of a flame :) I do not love WSGI, i am pretty sure the vast majority of people (even in WEB-SIG) do not like it, and are demanding for a new approach. But it is here, all of the python web frameworks use it. We have to live with it :) If a user can/want to use Brubeck it will probably be able to use mongrel2 at its max, all of the others still need to rely on solutions like uWSGI or wsgid. -- Roberto De Ioris http://unbit.it
