I've been working on infinite streaming in Rails 3.1, here is my work so far.(youtube.com)
youtube.com
I've been working on infinite streaming in Rails 3.1, here is my work so far.
http://www.youtube.com/watch?v=AyRjFolajfE
7 comments
Maybe instead of that music someone could be explaining what is going on because I for one I have no idea.
Advice for people making screencasts: If you're not confident about your narrating abilities, at least include text bubble explaining the major points and steps you're trying to bring across.
Unfortunately, the music backtrack overshadowed any easy learning experience here.
Unfortunately, the music backtrack overshadowed any easy learning experience here.
Saw the 1.9.3dev at the end. New hotness required for what you did or just for giggles?
The JSON streaming stuff is in 1.9.3, but you can do the same thing with yajl. :-)
Good stuff. Let me know if you need any testers. :)
That is soooo cool! Can't wait to try some realtime apps with that! :)
Sweet. Do the normal one connection per app instance rules apply?
Was going to ask something similar. Seems like single-threaded apps might have a tough time with this approach, but probably outside the bounds of this discussion.
This kind of app is perfect for non-blocking I/O.
I don't know what he does there, or what would be the equivalent for Ruby/Rails (that time.sleep(1) doesn't look good), but in Python one could use something like Gevent for long-pooling, which uses livevent to implement micro-threads: http://www.gevent.org/
Here's a sample that uses Gevent/Django: https://bitbucket.org/denis/gevent/src/tip/examples/webchat/...
It's not the same thing, because when server finally sends a response, the connection is then closed. But it's trivial to write a custom WSGI middleware, that sends a chunk of stuff, then releases the thread for other requests.
And doing it this way, you could have thousands of connections open with a single server instance.
I don't know what he does there, or what would be the equivalent for Ruby/Rails (that time.sleep(1) doesn't look good), but in Python one could use something like Gevent for long-pooling, which uses livevent to implement micro-threads: http://www.gevent.org/
Here's a sample that uses Gevent/Django: https://bitbucket.org/denis/gevent/src/tip/examples/webchat/...
It's not the same thing, because when server finally sends a response, the connection is then closed. But it's trivial to write a custom WSGI middleware, that sends a chunk of stuff, then releases the thread for other requests.
And doing it this way, you could have thousands of connections open with a single server instance.
I just added the sleep to simulate "work". It's not really needed.
Could probably just use Rainbows! to handle the "long" polling aspect but I think Rainbows! still assumes that the request will eventually end so I'm not sure if it will work for something like this.
Edit: I tried to add "<3 <3 <3" to the title, but it did not accept it.