My personal opinion is that while architecturally one of the most widespread solution is long-poll or comet, from a development perspective, I don't agree that it's the easiest in the sense that it's a part of the way to do things: simply there's much more in a queue/pubsub system because of the load its backend has to bear.

Personally, I'd even consider plugging in an ActiveMQ server or some other message queue solution, as long as it has a notion of per-user queue, which can be drained by a client, and it has a JS API to drain, and perhaps a Ruby / REST API to push, it works.

But again, this is my personal opinion, that while yes, long-polling can be an option (or socket.IO can be), it's only a part of the equation, even if a major part.

The easiest way would be to use a long-poll. However, this is not push. A long-poll is a normal request, with some long timeout. If there is a message, the request will be answered. Your client receives the answer and starts the next request. This way you almost always have an open request, waiting for an answer.

Take a look at Bridge made by the creators of nowjs. It helps you push messages down to your clients very easily, whether you're building a Rails app or a Node.js app or even python apps. It supports a lot of languages and platforms. It's a very robust system that can handle billions of messages a day.