

Gevent, Long-Polling & You - toastdriven
http://toastdriven.com/blog/2011/jul/31/gevent-long-polling-you/

======
ssfak
Instead of "long polling" (or a different way to have long polling) is to use
the HTML5's server sent events (<http://www.w3.org/TR/eventsource/>) See here
for examples: <http://www.html5rocks.com/en/tutorials/eventsource/basics/>

I have implemented such a functionality for real time monitoring using gevent
and works extremely well. This HTML5 feature is supported in recent versions
of Chrome, Opera, and Safari and in the beta versions of Firefox, but not in
any version of IE: <http://caniuse.com/#feat=eventsource>

~~~
lightcatcher
Thanks for the links. I wasn't aware that server sent events existed. It looks
cool, but is just another thing that can't be used because of compatibility
yet :(.

------
simonw
Great article. I'd classify this approach as "streaming" rather than "long
polling" though - in long polling, a browser opens a connection to the site
which stays open until an event occurs, at which point it closes. As far as
the browser is concerned, the request just took a few seconds to return - so
the technique often bypasses dubious proxies and other issues (browsers have
been really good at dealing with slow loading connections since the modem
era).

Streaming is when the connection stays open and multiple messages are sent
down the single pipe. It's faster and more responsive (and easier to scale
since you don't have to deal with lots of connections being closed and
reopened all the time) but is tricker to get working.

Of course, WebSockets make everything work sensibly hence avoiding the need
for crazy hacks.

Here's a deck from a talk I gave on Comet back in 2008 which touches on some
of this stuff <http://lanyrd.com/2008/skillswap-goes-javascript/skq/>

------
pacoverdi
> [...] wondering about the yield ' ' * 1200 in there. [...] some browsers
> (like Chrome) will sit & buffer if there isn't enough data to start with
> [...]

Slightly off topic, but I wonder if this technique can be used to circumvent
the buffering that occurs in HTTP proxies? I encountered the problem once and
was only able to make the application responsive by closing the connection
after a timeout (forcing the client to open another one).

------
traviscline
Great writeup. This shows the power of gevent+redis really succinctly.

I think most importantly vs a twisted or tornado based solution this is using
the vanilla redis client library. As long as your datastore's client library
is pure-python it JustWorks with gevent.

Adding gevent-websocket and gevent-socketio to the mix gives some interesting
possibilities as well.

------
chaselee
Tornado (<http://www.tornadoweb.org/>) can deliver long-polling with a pretty
small amount of work as well, and I appreciate the simple, lightweight design
of the framework itself.

~~~
zaph0d
Sure, but Gevent monkey patches the stdlib and lets the programmer write code
in a synchronous fashion which actually gets executed asynchronously. That,
IMHO is a big win since it's easy to get stuck in the callback hell in
Tornado. I have used Tornado in production and it's an awesome
library/framework/server but things do get complicated when the app becomes
complex.

~~~
lightcatcher
I'm not as experienced with Tornado, but just feel like throwing in that
callbacks in a language without non shitty anonymous functions seems like it
would be miserable.

------
MostAwesomeDude
I went ahead and ported the pusher to Twisted, as a simple exercise; see
[https://github.com/MostAwesomeDude/wsgi_longpolling/blob/mas...](https://github.com/MostAwesomeDude/wsgi_longpolling/blob/master/txpusher.py)
for code.

Edit: And an explanatory blog post is at
<http://corbinsimpson.com/entry/summertime> for those readers not well-versed
in Twisted.

