Tornado: FriendFeed's non-blocking Python web server is now open source

Non-blocking sockets. Calls to socket.read() can return no data. It's non-blocking because the program is not stuck waiting for data to be returned.

"How many deployed web apps really use Twisted?"

This is sort of the point. twisted isn't a web framework. It's a networking framework. I work on a lot of really awesome networking projects that either don't have web interfaces (various xmpp services) or have ones that need work (buildbot).

Instead of filling an obviously missing hole in an existing framework, a new one was created that is missing all of the stuff that the other project has.

The twisted http client stuff is quite good. I used it along with a friend to build a tool that is a realtime (in the web sense) gateway between friendfeed and xmpp clients a couple days after the realtime API was released (before friendfeed launched their own). It works very well and I still use it today.

Unfortunately, if I wanted to build a tool that did similar stuff with a Tornado front-end, I'd have to write a new HTTP client that's compatible with Tornado's event loop (unless I'm mistaken).

Everything comes at a cost. Tornado demonstrably solved Friendfeed's problems quite well, but, as I stated above, I can't use it to solve my problems because even if I rewrote my apps, I'd lose all of the rest of twisted upon which I'm relying. e.g. I can't just bolt it onto buildbot (which would be so ideal as our web interface is suffering from lack of a framwork, but the backend is really good).

It seems like blocking calls to data sources (the database, memcache, etc) would screw with a lot of the benefits of running the framework asynchronously. If your Tornado processes freeze while making synchronous backend requests, you're gonna need a lot of them, which probably kills a lot of the value.

Now all we need are async data clients that tie into the Tornado event loop, and a clean way to yield control back and forth (perhaps with coroutines - http://www.python.org/dev/peps/pep-0342/). Unfortunately, I don't think there are any async Python mysql clients (PHP has one now - http://www.scribd.com/doc/7588165/mysqlnd-Asynchronous-Queri...)

A web app written like that would run like it's on fire. The event loop would just roll through everything asynchronously. You could even automatically batch together data calls across http requests to make things easier on the data tier.

The templating system they developed looks pretty sweet http://github.com/facebook/tornado/blob/master/tornado/templ....

Just played around with it a bit and it's basically what I want:

1) Simple and clear syntax (e.g. they use 'end' not endfor, endblock, etc)

2) Assign template variables to anything (including functions)

3) Don't over-restrict the author (e.g. they allow list comprehensions in if tags)

4) Block and extends statements.

Error handling seems to be a little clearer than other template languages though still not great:

http://gist.github.com/184934

Clearly it's not going to be for everyone but after slogging around with Mako for the last year ( tags anyone?) this is like a breath of fresh air.

I'll brainstorm the idea. I have some ideas of how to turn this evented programming into a very natural flow using ruby 1.9.1's fibers.