4 ms·

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

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_minimal.py https://github.com/j2labs/brubeck/blob/master/demos/demo_min... * Flask style routing: https://github.com/j2labs/brubeck/blob/master/demos/demo_noclasses.py https://github.com/j2labs/brubeck/blob/master/demos/demo_noc...

lightcatcher 15y ago
Its relatively difficult to find maintained Mongrel2 Python libraries, but projects like http://wsgid.com/ http://wsgid.com/ , https://github.com/rfk/m2wsgi https://github.com/rfk/m2wsgi , and (maybe unmaintained) https://github.com/berry/Mongrel2-WSGI-Handler 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.
- j2d2j2d2 15y ago
  That's a fair point, but there's a lot to love about Mongrel2!
  - rfk 15y ago
    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)
    - lightcatcher 15y ago
      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.

lightcatcher 15y ago

Its relatively difficult to find maintained Mongrel2 Python libraries, but projects like http://wsgid.com/ http://wsgid.com/ , https://github.com/rfk/m2wsgi https://github.com/rfk/m2wsgi , and (maybe unmaintained) https://github.com/berry/Mongrel2-WSGI-Handler 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.

j2d2j2d2 15y ago
That's a fair point, but there's a lot to love about Mongrel2!
- rfk 15y ago
  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)
  - lightcatcher 15y ago
    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.