The difference here is that Brubeck answers ZeroMQ messages from Mongrel2 instead of being a web server. So instead of using WSGI, Brubeck connects to Mongrel2 via a ZeroMQ socket and reads messages representing the web requests.
Beyond that I attempted to create a familiar interface for everyone who's used a pythonic web framework before. Indeed, a lot like Flask, but also like Tornado.
Agreed. If you limit your application to WSGI then mongrel2 is "just" another high-performance event-driven webserver. To really take advantage of the advanced features of m2 you need a framework that's more closely tied to its model of the world.
(speaking as author of the m2wsgi module linked above)
I haven't done anything significant with Mongrel2 yet, so my mental model of its operation is probably somewhat flawed, but I was thinking about my above post for a while yesterday.
It seems like WSGI supports a subset of Mongrel2 features. Any "pure" WSGI app can run fine behind Mongrel2, but Mongrel2 allows much more than the WSGI model. For example, a response in Mongrel2 is just a socket getting written to. Mongrel2 can send a request to server A, and then receive the response from a completely seperate server B. Can WSGI support something like this? As far as I know, someone would need to reimplement a lot of Mongrel2's functionality in Python (which is idiotic) just for WSGI compliance.
Again, I've yet to build anything with Mongrel2 and I haven't read the WSGI PEP in a while, so please correct me if I'm wrong about anything. After thinking about it yesterday, I find the differences between a more traditional WSGI-esque model and something like Mongrel2 to be fascinating.
I wouldn't use Brubeck without WSGI solely because I don't want to write an app dependent on its web server.