interesting! any opinions on celery vs RQ or on asyncio? does [asyncio is for composition](http://www.onebigfluke.com/2015/02/asyncio-is-for-composition.html) ring true for you? i haven’t actually used asyncio (tulip, trollius, etc) in practice, only hand-rolled generator frameworks, so i’m always interested in stories.
RQ is pretty perfect for my use case (small number of infrequent jobs). I’m on a 512mb VPS, so I really appreciate that it forks a short-lived process for each task. The master only uses like 10mb (as opposed to Celery which was closer to 50-70mb, which is still pretty small but enough to run out of memory on my tiny server).
Asyncio is awesome (though it makes me a little sad that gevent vs. asyncio widens the gulf between Python 2 and 3 instead of narrowing it). So this is literally the entire server for proxying messages from redis to websockets (and here I thought @aaronpk’s node implementation was as simple as it could get). It’d be interesting to apply async to all the polling woodwind does; could be a great use case for it. And @haxor’s post totally rings true, I hadn’t seen it before thanks for sharing! A lot of the even fairly trivial stuff we do in indieweb apps is bound by more than just the database.
Thaaaat said, all I really want is to hold open a few HTTP connections and stream events to them. It seems like something that everyone would want to do, and this solution with redis and a background process running on a separate port still twinges that “isn’t this more complicated than necessary” part of my brain :)