Thoughts on technology and social web

July 17, 2009

Real time roundup

Filed under: Cloud Computing, NextWeb, Real time web, Social Networking — Ravikant Cherukuri @ 6:50 pm

Real time web has been a favorite topic for me for a while now. I work on one of the large IM systems and am very interested in these developments. Real time web started emerging as the platform for the next web in the last year it two. The main idea here is that events happening on the web are brought to you as they happen. Think the coverage that the iranian election aftermath got with twitter. The more obvious scenarios are already a reality and there are several more subtle but equally impressive usages that many are working on. As with all technologies that are driven by guy-in-the-garage start ups, its tough to see where this is all leading (if at all). Real time web focuses on several aspects of the web.

  • filtered web streams
  • instant delivery of web posts
  • real time collaboration
  • responsive web applications
  • S2S data filtering

The lack of full duplex connectivity has been a down side of HTTP. This gave native applications a one-up. HTML5 is out to correct that with Web Sockets. Meanwhile, technologies like COMET, BOSH etc provide a near real time connectivity over HTTP. So, the technology seems to be in place for the real time web. But why does real time web matter? We already have near-real-time, polling based push technologies like RSS/Atom. In my mind the answer is user experience. Real time gives the most natural experience. Compare a walkie-talkie to a telephone. A walkie-talkie is near real time with a lot of user level sync. Its just a quirk of technology. A telephone conversation is a full duplex real life conversation. Makes a lot of difference.

More links to the real time web :

Introduction to the RealTimeWeb

The Real-Time Web – O’Reilly Broadcast

Is Real-time the Future of the Web?

Building Real Time Web Applications Using HTML 5 Web Sockets

How to Deal with the Real Time Web: Navigating the River

Real time search and filtered streams

For me the coolest part of microblogging is real time search. The significance of most information rapidly fades over time. So, getting short spurts of information as and when it happens is super userful. Twitter’s hash tags are a good example. You follow information rather than people. I find the following ways to track real-time information interesting.

  • Twitter hash tags. Send something like #iwant in the tweet and people can easily track your tweets and might contact you if they are selling what you want. Gives meta data  to your tweet and makes it trackable by other users. The #iwant and #ihave tags are a good example. There are third party sites that consume the twitter firehose and build a realtime marketplace .  Such mining verticals on real time data are fast emerging. Many hugely popular twitter games like spymaster are another example.
  • Google’s “e-mail me when a new item is found that matches my search criteria” feature. This is super useful. If you know what you are searching for, you can be the first to find information as it comes live. Google can deliver this to you with in a few hours of the informations getting posted on web. This is realtively real time (compared to others) but is still a push. When this becomes true real time, it will be awesome.
  • Aggregated real time search. There are several real time search engines out there that can get you real time feed search from twitter/facebook/identica etc in one interface. Some of these have AJAX powerd interfaces and some have true real time with XMPP (collecta).

The basic idea behind this is to subscribe to receive changes data on the web without tying in to specific web sites, in real time. Eventually, the bigger search engines like google/yahoo/bing will comeup with a tighter integration of real time into all of the web that they index. With that, real time search will seamlessly integrate with the normal web search as we know it.

Instant information delivery

This category of real time applications aim to deliver your data of interest to you as soon as its posted. Sample scenarios here include

  • Deliver blog posts and comments that you are interested in instantly. This builds on the current RSS based systems by bringing true real time to content delivery.
    • : Word press now allows you to keep track of other word press blogs and comments and comments on your wordpress blog over XMPP IM with clients like GTalk.
    • Tweet.IM delivers your twitter feed over IM in real time using XMPP
    • Friendfeed aggregates feeds form all your friends blogs, social streams and comments. Friendfeed has a feature that delivers these are friend feed finds them over XMPP IM.
    • Google Wave uses XMPP IM protocol to sync wave content in real time.
    • There are a couple of startups like iNezha that provide real time updates to all the blogs that you are interested in.
  • Enable efficient content aggregation uisng XMPP. Google PubSubHubub is a good example. There were also several experiments by companies like Gnip, FriendFeed etc to use XMPP for this purpose.
  • IM systems are integrated with email systems (by the same vendor) today. You get an email and you are presented with a toast my the IM system in real time.
  • Windows Live Messenger also supports alerts from different third party providers. This is real time events from arbitrary providers with whom you have registered your interest. You can click on the windows live alerts button on my blog and get alerts onto your messenger whenever I update my blog.

[More to come in a later post]

June 19, 2009

Protocols for the real-time web

Filed under: NextWeb, Social Networking — Ravikant Cherukuri @ 5:46 am

Today Collecta unveiled their real time search engine toady. One of the several players in this fastly evolving space. Others include twitter search, OneRiot, Tweetmeme, Facebook search, rumored google real-time search etc. The interesting thing about collecta is that they are true real time. You will see updates reach you within seconds (of collecta seeing them). This is because they use Jabber’s XMPP protocol to push updates to the client. This is one of many techniques used for real time communication on the web. Some invented as people needed them and others like XMPP that are standardized. What are these techniques and how do they stack up?

As early as 10 years back, we started seeing applications that tried to bring you information as it changes or as it is created on the web. This evolved into RSS/Atom based feeds. This is a polling based pull that simulates push. Your browser or blog reader will periodically poll for changes to your feeds and update you when they change. This evolved into feed aggregation services where all your feeds are aggregated into a single feed that you can poll from the client. This makes it efficient to poll on the client but the serivce that is the owner of the feed still gets the load. Consider this. For the web to be real time, the zillions of objects on web from product listings to blog posts to wikipedia articles have to be able to communicate to users in real time. The feed model just dosent scale to this.

As the web UI evolved we needed web applications to be more responsive and so AJAX was born. AJAX (Asynchronous Javascript And Xml) enabled javascript to make XML based calls to the web server and get data back to the current page without reloading it. This made web apps more responsive but the model is still the same as javascript now used XMLHttpRequest to poll feeds from the server.

Then consider real time collaboration scenarios like instant messages, collaborative document editing etc. These need real time responses as other users are watching the screen to see them. These applications need to be more realtime and constant polling will either overwhelm the servers (for short polling interval) or degrade user experience (with longer polling interval). Long polling / Comet comes to the  rescue here. The browser keeps long running connections open with the server so the server can send events to teh browser as they happen. The basic technique is for teh browser to make a request to the server for which the server does not respond till it has some data to send. Once the browser gets some data from the server, it make another request to the server. Many web apps like gmail, facebook, meebo etc use this technique to bring real time functionality to the web.

These techniques are also used by APIs that bring realtime to web by implementing web wrappers around existing proprietary realtime protocols like Messenger Web Toolkit,  Web AIM, Yahoo messenger SDK etc. The Messenger web toolkit provides a cool feature that allows you to send non IM messages that can be used to build higher level collaboration applications.

The Jabber/XMPP protocol is an extensible protocol that is used for publish-subscribe (mainly in instant messaging). This protocol is finding way to many real time web scenarios like –

  • real time search (Collecta), twitter (, friendfeed,
  • aggregators like PixelPipe and that let you interact with your social networks via XMPP,
  • WordPress firehose where partners like search engines and market intelligence providers who would like to ingest a real-time stream of new posts and comments the second they get published.
  • Twitter firehose where thrird parties can get the realtime stream of twitter data to mine and search.
  • Google wave extends XMPP to build a collaboration system

XMPP also has javascript API for the web like Strophe and xmpp4js. There is a technology similar to comet for XMPP to run on HTTP called BOSH. BOSH takes care of firewall traversal and tunnels XMPP over HTTP. Overall this is a fairly well designed and extensible protocol with a lot of good documentation and several reference implementations. This is becoming the protocol of choice for the real time web.

There is also the WebSockets API in the HTML5 specification. The HTML 5 specification introduces the Web Socket interface, which defines a full-duplex communications channel that operates over a single socket and is exposed via a JavaScript interface in HTML 5 compliant browsers. It tarverses firewalls and proxies and provides bi-directional transport with streaming capability without the long poll overhead. The javascript API is also very simple. COMET can surely take advantage of this and things become more straight forward without hidden iframes and arcane protocols. So can XMPP. Sounds like the holy grail in making the browser a two-way real-time medium.

This space is fast changing and a lot of smart folks are figuring out how to make the web more responsive and realtime. And the protocols keep evolving to acocomodate that.

Update : There is a good article about XMPP progress in 2009 at

June 18, 2009

HTML5 – the way ahead

Filed under: NextWeb — Ravikant Cherukuri @ 4:17 am

For many web developers, even though web 2.0 and AJAX was a gaint leap, we were stuck in a place where the HTML 4 (and its many interpretations) was restrictive and there is still a difference between the look and feel of a well designed desktop app and a well designed web-app. Adobe flash, AIR, SilverLight etc attempt to bridge this gap. But what if HTML could do it all. Can JavaScript be powerful enough to do all the things that C#/ActionScript can do? Can HTML5 carry forward the experience and knowledge collectively gained in the last 20 odd years of UX programming? The HTML5 standardization process is going to take a few more years, but browsers are already implementing the draft standard. For developers and companies to invest in HTML5, we need a firm commitment from the browser makers. Especially since the last iteration did not go well.

Browser Alert

In the current imperfect world, HTML4 itself did not realize its potential because of the interpretations that different browsers made of the standard. The end result being all the browser specific quirks that developers are forced to learn. IE (6/7/8), Firefox, Opera, Safari and now Chrome all of them need to get their act together. The user has choice today. So better get your act together or people will move to a different browser. This is the biggest hurdle for HTML5 and also a key test for browsers.

Flashy without flash

I started looking at HTML 5 like many others after watching the google wave demo. The fluidity and interactiveness of the interface is amazing.

A few more examples of what HTML + Javascript could do. Here is a visual studio like editor in HTML developed by firefox.

Firefox 3.5 implemented the video tag of HTML5. This is a really awesome demo.

OTOY is a company trying to take your console into the cloud. It does all the graphics processing on a server and just renders the picture onto your browser with no plugins or downloads. How cool is that?


What does HTML5 have that makes it powerful? There are several new features in HTML5 (list from wikipedia). It brings many patterns of usage today into the language.

  • New parsing rules oriented towards flexible parsing and compatibility
  • New elementssection, article, footer, audio, video, progress, nav, meter, time, aside, canvas, datagrid
  • New types of form controls – dates and times, email, url, search
  • New attributesping (on a and area), charset (on meta), async (on script)
  • Global attributes (that can be applied for every element) – id, tabindex, hidden
  • Deprecated elements dropped – center, font, strike, frames

The canvas tag makes it possible to get flexible drawing into the realm of HTML. I have used other javascript apis that simulate a canvas. These work by drawing 1 pixel divs that are absolutely positioned. The canvas tag is way more economical and elegant.

At last there are combo boxes that are native in HTML using the datagrid tag.

The input tag now has many new types – datetime, datetime-local, date, month, week, time, number, range, e-mail, url, search, color. The progress tag will display a progress bar. It was so dumb that there were 100 different implementations for these. Many other new tags provide HTML native versions of elements that were not natively supported and resourceful javascript junkies had to hand code (figure, footer, header, meter etc)

The video/audio tag (as seen in the firefox demo above), provides rich video/audio embedding and manipulation capabilities natively in HTML.

WebSockets API that provides in-built support for two way communication. This is a good idea with the proliferation of real-time web applications with long-poll/COMET etc. This might take us to a true real-time duplex connectivity. An interesting comparision of AJAX/COMET to HTML5 can be found here.

The <script> tag has an async attribute that makes the page load to continue while the script is loading. This will speed up page loading and improve user experience. With the complexity and size of the scripts on the rise, this is very handy.

The browsing context defines the algorithm that browsers use for navigation and the related sessions history traversal. A browsing context is an environment in which Document objects are presented to the user.

Session history and navigation using javascript APIs.

Cross domain communication using Window.postMessage. This is already in most browsers and what a relief. The earlier cross domain communication techniques (hacks) relied on changing the hashes (the test that follows #) in a URL and a background timer. eeeks!

Offline web application caches. Google gears/Windows live mesh etc have build this with no browser support in a non standard way. Now HTML5 defines this as a standard. The ononline and onoffline events give javascript the ability to track connectivity and will enable the AJAX application to behave accordingly (detailed article).

DOM Storage as a way to store meaningful amounts of client-side data in a persistent and secure manner. John Resig of the jQuery fame wrote this article that explains this in detail. Looks very powerful and can be used to enable and optimize many desktop app like scenarios.

Editing API in combination with a new global contenteditable attribute and something called an UndoManager that will support undo/redo for content edits. Sounds good for a totally in browser content editors and development environments.

Support for spelling and grammar checking. Some drag and drop support. Many link types to give meaning to links. This looks like part of micro-format and semantic web support.

Frankly i thought there would be more to support semantic web, linked data and such. But may be there is. This spec is a work in progress (a mess). Somewhere it mentions that the HTML5 spec has a lot of things that should have their own specs but due to the lack of volunteers to own the specs, all the stuff got dumped into one. Sad for such an important piece of work.

With all these features and many more that i could not get to, HTML5 is aiming to bring the flexibility and performance of desktop applications to the web. I am sure over time, these features will get better defined so that they can be interpreted without ambiguity. This is important to make web application work cross browser. The more I read about this stuff, the more I am convinced that this will succeed and take over many of the scenarios that are served by Flash, AIR and SilverLight. There might still be some applications where these will stay relevant. But if you are looking for state of the art presentation and interactivity, HTML5 will do it.

Developer’s Woes

jQuery and prototype are two JavaScript libraries with a lot of promise. Take a look at jQuery Tools and what HTML4 can do. With HTML5, and all the new functionality, javascript now is a very complicated (and powerful) language. How do you handle your application complexity and size as yout javascript, HTML and CSS grow in size? There are many solutions for managing HTML like ASP.NET, JSP, PHP etc. How about your javascript? How would you unit test your javascript code? How would you make it reusable?

One option is to go with libraries like prototype and jQuery that make it very easy to do common tasks and if you buy into their design philosophy, its a very compelling was to design your code as well. JavaScript is powerful and elegant. If you know how to write good code that is. Its not very difficult to get a hang of it. The advantage of this approach is that you stay true and antive to JavaScript and can take advantage of the fast pace of innovation here. The prototype library has unit test support too. Never used it myself though.

The other option is to use the “more evolved” server side languages like java or C# to write your code and use a cross compiler to generate the javascript for you. GWT (Java -> JavaScript) and Script# (C# to JavaScript) are good examples here. There are also other cross compilers like pyjamas (Python -> JavaScript), Objective-J (Objective-C to JavaScript). The advantage of using one of these approaches is that you could use your native language (if its not already JavaScript). You can use a development enviroment that is built to handle size and complexity (like Visual Studio/Eclipse etc) and take advantage of features like intellisense and refactoring tools. You could also leverage existing unittesting frameworks. Quite a few complex AJAX applications on the web today use this model.

If HTML5 is to replace the other desktop application development technologies, it would need more powerful and integrated tools so that you dont have to be an expert to develop these apps. The HTML WYSIWYG tools have to evolve to support not only the language features but also the common patterns so well designed software will be easy to do.

Will update this blog with more exciting HTML5 thingies as I find them.

Blog at