Re:I've been working on infinite streaming in Rails 3.1, her...
by jschuur on Wednesday April 06, 2011 @05:41PM
(#2417106)
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.
Re:I've been working on infinite streaming in Rails 3.1, her...
by bradhe on Wednesday April 06, 2011 @05:31PM
(#2417065)
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.
Re:I've been working on infinite streaming in Rails 3.1, her...
by bad_user on Wednesday April 06, 2011 @05:48PM
(#2417132)
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/
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.
Re:I've been working on infinite streaming in Rails 3.1, her...
by PatrickTulskie on Thursday April 07, 2011 @09:55AM
(#2419442)
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.
Unfortunately, the music backtrack overshadowed any easy learning experience here.
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.