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.
It's for the better. WSGI is a piece of crap. Try getting a decent stack trace out of it's weird "we hate callbacks so we did nested function calls instead of lists" design.
I don't understand what you're saying. What do you mean by "nested function calls," and how is that antithetical to both lists and callbacks? In what way is WSGI anti-callback?
WSGI is fine if you're building short-lived, simple request/response style web apps but if you want to do any sort of async messaging, long-polling, or use websockets i.e. a modern web app - then it leaves a lot to be desired. Mongrel2/Brubeck appear to be designed with these considerations in mind.
Comments
Armin Ronacher—author of Flask and Werkzeug—pointed out earlier on Twitter[1] that (for better or for worse) it doesn't support WSGI.
[1] http://twitter.theinfo.org/92202624614539264
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.
* Tornado style routing: https://github.com/j2labs/brubeck/blob/master/demos/demo_min...
* Flask style routing: https://github.com/j2labs/brubeck/blob/master/demos/demo_noc...
Its relatively difficult to find maintained Mongrel2 Python libraries, but projects like http://wsgid.com/ , https://github.com/rfk/m2wsgi , and (maybe unmaintained) https://github.com/berry/Mongrel2-WSGI-Handler make it fairly easy to run WSGI apps behind Mongrel2.
I wouldn't use Brubeck without WSGI solely because I don't want to write an app dependent on its web server.
That's a fair point, but there's a lot to love about Mongrel2!
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.
It's for the better. WSGI is a piece of crap. Try getting a decent stack trace out of it's weird "we hate callbacks so we did nested function calls instead of lists" design.
I don't understand what you're saying. What do you mean by "nested function calls," and how is that antithetical to both lists and callbacks? In what way is WSGI anti-callback?
WSGI is fine if you're building short-lived, simple request/response style web apps but if you want to do any sort of async messaging, long-polling, or use websockets i.e. a modern web app - then it leaves a lot to be desired. Mongrel2/Brubeck appear to be designed with these considerations in mind.