Chromecast URL Player

I was annoyed by the fact that the Chromecast SDK has been out for the public for quite a while and yet googling for a simple URL player for Chromecast did not yield satisfactory results. So I sat down to create my own simple web app for playing back any http video or viewing any still image in Chromecast.

URL: http://movies.foamsnet.com

Source Code: https://github.com/vickyg3/UrlPlayer

Would love to hear feedback. Feel free to fork, send pull requests.


-Vignesh

Open sourcing Social Photos

I have been working on a lot of open source projects lately (chromium, AOSP, ffmpeg, etc.) and I have had this tremendous change in the way i look at software projects now. I am all the more convinced that open source is the only right way of doing software.

With that in mind, I've made a pledge to myself that no matter what I do, I am going to put the source out there. As a first step, i'm open sourcing the one big project of mine, Social Photos.

The source can be found here: https://github.com/vickyg3/social-photos

It is a snapshot of the one that's currently powering the live site: http://socialphotos.net (with API keys redacted). Feel free to fork and use as you please. Although i'd appreciate a link back, it's not mandatory. Also, i'll be more than happy to look at Pull Requests.

One of the main reasons that developers (including myself) don't post our code out there is that we are ashamed of our code. I was really ashamed by the number of hacks i did in this project that i couldn't even think of making it public. I'm over it. I'm ready to accept people fixing my mistakes.

Happy Coding!

-Vignesh

Serverless Downloads - HTML5 Awesomeness!

HTML5 brings an awesome feature known as client downloads. At first glance, the term "serverless downloads" may sound oxymoronic, but it sure makes a lot of sense. In the HTML5 era, we write a lot of thick clients. All the day to day web apps which we use are damn thick (Gmail, Facebook, etc.). So in the context of thick clients, serverless downloads make a lot of sense.

Content-Disposition HTTP Header

On the web 2.0 days, when you wanted to force a browser to download a file to disk rather than displaying it (especially if the file is of some format which the browser is capable of rendering), you used to set the Content-disposition header in the HTTP response.

Content-Disposition: attachment; filename="sample.txt";

There is no way for the browser to let the user download the file without contacting the server, even if the contents of the file were to be generated totally on the client side.


The Problem

This is old school. These days there are lot of web apps where you create the data on the app itself. For example, consider Google Docs, you create all sorts of documents on the web. Every time you click the download button, the data is sent to the server and the same data comes back along with required filetype's additions and you see the download dialog box.

This step seems too radical and unnecessary. Given how thick the clients are these days, it is atrocious to send some data to the server and get back the same data as a file from the server. The same holds for all sorts of web based photo editing apps, etc.


The Solution - "download" attribute

Now with HTML5 it is possible to generate a file on the client side and make the user download it without contacting the server at all. The simple addition of "download" attribute to the anchor(a) tag will tell the browser to download the content present in the "href" attribute rather than navigating it. Now, this can be combined with a "blob:" or a base64 encoded data url to create a file and download it, all on the client side.

I have put up a demo where you can enter text into a field and then download it as a pdf.

Demo: http://garage.foamsnet.com/static/pdf.html
Image Courtesy: http://www.html5rocks.com

-Vignesh