We live in the realtime web era. There are different appreciations of what realtime web is. To me, the best definition is that it means the content is pushed from a publisher to a subscriber, rather than have the subscriber poll the publisher over and over. Today there exists a bunch of different realtime web technologies. Let’s review a few of them.
Realtime web in the browser
This is probably the most commonly observed technology. It goes from Netvibes’ page which updates by itself, to Twitter’s new published tweets, via Tumblr’s new items. Basically, your browser communicates with a service’s server and this one is able to push updates to it. They use different techniques and it’s not uncommon so see people naming for the other. You can also easily find providers for these solutions, like BeaconPush, PusherApp or Kwwika.
Ajax
It relies on Javascript and is not technically a push . What happens here is that the client’s browser is able to send “smaller” requests to the server, which do not generate a full reload of the page, but just bits of it. Even though the Same Origin Policy prevents the browser from doing calls to a server that is not the one from which the whole page was loaded, a few techniques, like JSON-P can allow developers to bypass this limitation.
It’s far from perfect and can be very heavy on the publisher’s side, but it’s also one of the most frequents techniques and probably one of the oldest and easier to implement.
Comet
This one is often called “long-polling” too. The idea here is that the initial request made by the browser to get the content is actually never closed by the server, which means that the server can still push to the line a few more bits of information. This is what GTalk uses to show you chat messages. This is also what Friendfeed used to do does, and their Tornado WebServer is particularly suited for this purpose. So instead of having the server to handle millions of requests per seconds, it needs to keep thousands of connections open. At the same time, it may be a little faster to show updates to the client, because it doesn’t have to wait for the client to ask for them (that’s actually push!).
WebSockets
Both Ajax and Comet feel like hacks and what they allows was obviously not in the mind of those who designed HTML. Luckily these experiences have pushed (pun intended) the W3C to think a little bit about a native solution to HTML so people would have an agreed upon standard that meets the realtime requirement. The came up with WebSockets. Even though they’re not yet supported by all browsers, we can safely bet that they will be the standard as it will be part of HTML5 requirements. It’s basically a 2-way communication channel between the browser and the server and both can send and receive data on this line (comet is uni-directional).
Realtime web for Mobile & Desktop
More and more we consume the web from outside the browser, as Wired tried to show us. Whether it’s with a phone, a Tablet or even directly integrated in the OS of our desktop applications.
To the Phone
Heard about SMS? This is push data from a publisher to a subscriber. The UX isn’t all that magic, so Apple went live with their Push Notification Service which allows app builders to push data down to the phones where the app is installed. The fine people at UrbanAirship
have built an awesome wrapper around the systems from Apple, Android and Blackberry because they all require a significant amount of work. Blackberry actually is quite famous for their BlackBerry Enterprise Server which is dedicated to emails mainly. There is a lot of different techniques and protocol, most of them close and proprietary, but that’s how the telephony industry rolls it seems :)
To the Desktop
Oddly enough (or because this is due to the close presence of a web browser), most desktop OS do not offer the ability for the web to talk to the machine in an push way. Of course, Apple’s Dashboard can show you the weather or stock tickers, that are taken from the internet, but all this is pulled, not push.
Hardcore Mac Users have known Growl for a while, it’s a local notification server that can show messages on the screen. By design, it is very hard to add external services notifications to growl. But this is probably about to change. Yesterday, Chad and Stammy from Notifo released a desktop application.
Of course, there is another way, once that was barely explored : XMPP. Almost everybody has a chat client running on their computer. This chat client can certainly talk XMPP. So technically, it is possible (and it should be easy too) to send messages from the web down to the desktop, thru our chat clients. The few attempts focused way too much on a “chat” approach with text messages. Let’s hope that someone comes up with a much better solution in the near future. What about a combination of Readability, Growl and iChat?
Server to Server Realtime web
According to me, this is the highest mountain to climb in the realtime web sector. The objective here, is to allow information to flow from a service to another, rather than have everybody poll everybody else.
Tackling the Server-to-Server issue involves dealing with the transportation problem and the data format problem. Not only do service A and B need to emit and receive the same kind of signal, but they also need to speak the same language.
For the transportation, there are very few protocols. XMPP and PubSubHubbub are the ones Superfeedr chose, because they’re both open, which means that anyone else can implement them and we should be able to work together in a loosely coupled way (without business agreement).
For the data, we chose RSS and Atom feeds (XML), because almost everybody out there has them. Of course, some people also have their own JSON based APIs, but who said we should only speak one language?
A lot of people wonder why they should start getting content from other services or even push their content away. Many applications would rather focus on pushing down to the browser or build their own iPhone apps rather than push their content away. We think it’s wrong, because allowing your content to be pushed to other providers means that these providers can then implement their own iPhone apps, Growl clients, or even web clients with your content and bring you more users or grow engagement for your existing users.
This will conclude this loooong sunday post. I hope you haven’t all been lost on the way, and if there was one thing that I want you to take out of this is : start to push your content to other servers and make sure you can also subscribe to content from other servers. The web experience will just become insanely better.
Comments