Hacker News Reader

Comment by jconley | Hacker News Reader

Yes, it's definitely still polling. It is polling about once per minute. However, at least it's only polling at the application protocol level, not the connection level. Browsers and the GRIP proxy support keep-alive so the same TCP connection is very likely to be re-used for quite a while.

HTTP by nature is request/response. To speak pure HTTP, there isn't a way around polling that I know of. Avoiding polling means implementing your own protocol over HTTP, or using WebSockets (see Comet or implementations in Socket.IO, Firebase, SignalR, etc).

View on HN

There is actually a way to do streaming over HTTP without doing WebSockets. It's called "Server Sent Events" and is implemented in the EventSource API in Chrome, Firefox and Safari.

It's quite easy to fall back to long polling in older browsers and it's a very simple and straight forward format.

Yes you can certainly stream and do message passing within HTTP (for some browsers) but you can't, for instance, return headers more than once without your own application protocol.

The most interesting bit about this architecture for me is the 1:1 mapping with a pure HTTP resource. It's a bit like an implicit subscription to a pub-sub enabled resource. In this implementation we are simply calling our API like we normally would (except on the stream domain) and waiting for an update.

Or make life real simple and just use Socket.io

Will people stop writing crap "on" HTTP please and use TCP like you're supposed too! :)

Websockets is a great transport protocol for bi-direction realtime persistent connections. And it's very easy to write your own application protocol or just use WAMP from http://wamp.ws.

There's nothing wrong with using HTTP if it's done in a sensible way.

In the early days of the realtime web, long-polling was used mostly as an underlying hack in the emulation of streams. However, RealCrowd's API isn't a hack. When clients make requests to the server, they are attempting to synchronize a resource. One could argue that this kind of interface is semantically closer to what the client is trying to accomplish than one based around pure message passing.

Yes there are real problems with HTTP. There is a lot of overhead in building a connection and maintaining. It's designed to be a transient, request/response oriented protocol. Things like XmlHttpResponse are a hack and misuse.

I'm not just being pedantic about it either. Just compare server performance of RPC over Websocket to RPC over HTTP at scale.

Reply on news.ycombinator.com