There’s a log of talk about the real-time web these days, but most of it is talking about stuff that isn’t really real-time at all. Most of it just means when you access the data it is up to date, or in some cases it means things update for you every few minutes or seconds.
Google’s Feed API gives you access to any public Atom/RSS like data, including lots of Google’s own data. There was a lot of fuss recently about PubSubHubbub and I blogged about how PubSubHubbub is the not quite real-time web.
At Google I/O this week, Google will be announcing some changes to the Feeds API that enable updates to be pushed to browsers. ReadWriteWeb got the scoop on this posting that Google will push real-time feeds to browsers. Not just in terms of details yet, the video shows the code changes are minimal, but what is going on under the covers is what interests me. Is is really real-time? is it polling? Will they pick one, works for all, solution, or try out WebSocket for those that support it. For most things the Feed API will be used for the speed of polling is probably fine, but high frequency polling is just inefficient compared to true streaming. Long polling would sit somewhere between polling and streaming and a good compromise for the client end. What I am interested in is what implementation Google thinks is best for what could be the largest deployment of a web push service yet.