Google Chrome (Chromium) recently released a version of their browser with support for server-sent events. I used this technology and MVC to create a WebSlides application.

I created a nifty throw-away demo called WebSlides that switches between slides (PNG images). The slide show presenter navigates to a URL on their smart phone and is able to tap on back or forward links to change the current slide. The audience and the computer running the projector run a browser that points to another URL. As the presenter changes the slide all the clients connected see the updated slide.

What is a server-sent event?

Basically a server-sent event is a draft web standard that (on the ball) web browsers support to allow updates from the server to be “pushed” out to the browser. It is similar to WebSockets which has been all the rage (with cool experiments) but it is not a duplex communication channel. When you see the term “pushed” in regard to server-sent events you should note that what is actually happening is that the browser is actually polling a server URL. You can easily see this when you intercept traffic with fiddler. What it means though is you will not have to write the JavaScript to do the polling and it also gives you a way to only send data to the client when it is required. In my case I use it to update the slide the browser is showing when the presenter changes the slide.

How did I do it?

I created the WebSlides demo using MVC, I believe I am the first to create something like this as support for server-sent events is pretty fresh. I found that this guy created a chat client with cold fusion on the server-side which is pretty cool.

In my demo I created a new ActionResult called ServerSentEventResult that does all the heavy lifting you need to do make the browser happy.

So all you have to do is use it like this in your controller.

ServerSentEventResult eventStream = new ServerSentEventResult();
Follower followerModel = new Follower();
eventStream.Version = followerModel.Version;
eventStream.Content = () =>
    JavaScriptSerializer serializer = new JavaScriptSerializer();
    return serializer.Serialize(followerModel);

Another interesting point to note about my implementation is the lambda used to get the content, you may remember that the browser will poll the server to get events, so why make the server serialize data if it is not necessarily going to send it every request.

The rest of the magic happens on the client side with jQuery, If you have come this far I will leave it to you to dig around on github to see how that works.