Superfeedr Introduces Real-time Client Push Capabilities

Phil Leggetter
Dec. 20 2010, 12:00AM EST

Real-time feed parsing company Superfeedr just increased it's range of technology support which significantly increases the ease that developers can integrate with them. Developers can now connect to Superfeedr using only JavaScript. They appear to have covered all bases with this release by providing support for HTTP Streaming and WebSocket connections for real-time streams. Superfeedr aren't alone in offering real-time client push but they may well be the first to offer it as an extension of an existing service.

Superfeedr have been building a complex feed fetching and parsing infrastructure for quite some time now. This generally involves subscribing to, and redistributing, RSS feeds (although they've also just introduced support for "arbirary content"). This type of functionality has frequently been associated with, and restricted to, server technologies but Superfeedr have just changed that by adding real-time client push technology support so users can now more easily subscribe to feeds from thin clients such as web browsers.

Julien commented on the new server to client focus:

Superfeedr will release more products in this direction, with a greater
focus on Server to client, rather than Server to Server. Even though
having realtime server-to-server communications is required for a lot of
services and apps who publish to other 3rd party apps, or consume from
them, it's also obvious that having smarter clients who can display
realtime updates without any user interaction (like a refresh) is
becoming a necessity.

Superfeedr are very active at introducing new features based on customer feedback. It's just one of the reasons why they were recently listed as one of the top 10 RSS and syndication technologies of 2010 by Read Write Web. This relatively recent move to provide real-time client push has again been customer driven.

Julien Genestoux of Superfeedr announced the new functionality on the Superfeedr blog as two separate features - WebSockets and Comet - because it's now possible to make subscriptions using two additional methods. However, it's very possible that somebody will write a JavaScript library that hides away the underlying transfer protocol to choose the best connection method for the client runtime; the web browser. The reason this is likely to happen is that WebSocket support is still relatively low in browsers, the specification is still in its infancy and developers just want their real-time client push functionality to work no matter the web browser. WebSocket support has recently been disable in Firefox 4 and Opera due to a security vulnerability adding weight to this argument.

Julien provided his take on WebSockets:

The whole websocket adoption is a chicken and egg problem. Now that some browsers implement it, we need more apps to support it, so that the spec can evolve, become stabler (and more secure) to reach the next iteration and full support by all major browsers.

What this latest real-time client push move actually means for developers is that they don't have to write any server-side code to integrate with Superfeedr and they can add real-time client push functionality to their applications without the need for any complex infrastructure such as real-time servers.

As far as I'm aware Superfeedr are first company to add real-time client push functionality to their service without it being their core focus. Is this trend set to continue and what will the demand for it be like?

Phil Leggetter Developer Evangelist at Pusher, Real-Time Web Software & Technology Evangelist, team leader, product developer, micropreneur, managing director of a real-time web and social media software company, blogger and twitter user (@leggetter).

Comments

Comments(6)