On Mon, Sep 14, 2009 at 4:30 AM, Bret Taylor <[email protected]> wrote: > > I am one of the authors of Tornado (http://www.tornadoweb.org/), the > web server/framework we built at FriendFeed that we open sourced last > week (see http://bret.appspot.com/entry/tornado-web-server). > > I just checked in change to Tornado that enables you to run any WSGI- > compatible framework on Tornado's HTTP server so that Django apps > could run on top of Tornado's HTTP server and benefit from some of the > performance work we have done. (I just sent a message to django-users@ > with getting started instructions as well, but if you are interested, > take a look at > http://github.com/facebook/tornado/blob/master/tornado/wsgi.py#L188).
This is awesome news, Bret! I've only taken a brief look at Tornado so far, but it certainly looks interesting; having easy support for WSGI (and therefore Django) makes it even more compelling. > I chose the WSGI approach because it is generic and applies to all > frameworks, but Django is obviously the most widely used. I am curious > if there is any benefit to implementing more "native" support in > django.core.handlers or if WSGI is the preferred way of adding support > for new servers. If there is any performance or usability benefit, let > me know, because we would be happy to contribute our time to make it > happen. I'd be surprised if there aren't some friction points that could be optimized by using a Tornado-native interface, especially if you're looking to exploit some of the specific capabilities of Tornado. However, this leads us to an interesting chicken-and-egg situation. No offense intended to yourself and the great work you have done, but Tornado isn't a major market leader (not yet, anyway). The Django core team is very sensitive to the fact that adding something to the Django Core is effectively seen as "blessing" something as stable and worth using, and Tornado hasn't been around long enough in the public sphere to warrant that kind of recommendation. At least initially, I'd prefer to see Django-Tornado support as a project external to the Django core. It's all just Python code, after all - having a Tornado handler in the Django tree rather than somewhere else PYTHONPATH doesn't make the underlying functionality any more or less accessible. The existing mod_python and mod_wsgi interfaces could easily live outside the Django tree; they're just present as part of the 'batteries included' strategy that covers the most common mechanisms for deploying Python-based web applications at present. If, in the process of building and external Django support library for Tornado, you find that it is necessary to modify the core in order to support a particular feature of Tornado, raise a ticket in Django's Trac instance, start a discussion on this mailing list, and we'll look at making that change. This externalized approach would also be in the interests of the binding anyway. The rapid release/update schedules required by a new and emerging project aren't really compatible with an established framework like Django where the initial rapid development effort has plateaued and been replaced with a slower process of incremental updates. Long term, it may be appropriate to integrate Tornado support into the Django core, but it would be better to wait until the interface has matured before we look at integration. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
