I have been digging pretty deep in to the OpenSocial API. My interest has been mainly focused on the building of the containers which hold the OpenSocial applications. There is a lot on confusion about what OpenSocial is and why it is interesting. I'll be honest, it took me a bit of searching to really understand what OpenSocial is and how it is organized. I'll try and explain the what, a little bit of the how (more will come later), and my impression of the why it is interesting and might succeed. You already know the who (Google), where (the Interweb), and when (November 1, 2007-present).
What is OpenSocial?
OpenSocial is an API. Actually, it's two types of APIs. First, the REST API is designed to export the profile, friendship, activity, and persistence components to the social network (or any other application where these principles can apply) implementing the API. Second, the Javascript API is geared towards "OpenSocial Applications" and effectively does the same thing as the REST API, but in the form of a set of Javascript classes and functions.
The Application
The OpenSocial Application deserves some further clarification. At the 10,000 foot level an OS App is similar to Facebook Applications. The format is taken from the iGoogle gadget. It boils down to an XML file which includes metadata and wraps the HTML and Javascript that is ultimately rendered to the user. Here is a sample from Last.fm's OpenSocial Application (http://www.last.fm/opensocial/myfavouritemusic.xml):
<?xml version="1.0" encoding="UTF-8"?>
<Module>
<ModulePrefs title="My Favorite Music">
<Require feature="opensocial-0.5" />
<Require feature='setprefs' />
<Require feature='dynamic-height' />
</ModulePrefs>
<Content type="html">
<![CDATA[
<div id="overlord">
<div id="loading">Loading...</div>
<div id="updating" style="display:none;">Updating...</div>
<div id="area"></div>
<div id="lastfmAccount" class="lastfmAccount">
<div id="hadALastfmAccount" style="display:none;" class="strongLinks">
<p><a id="haveAccountLink" href="javascript:;" onclick="$('setUsername').toggle();_IG_AdjustIFrameHeight();new Effect.ScrollTo('setUsername');return false;">Have a Last.fm account? Click here.</a></p>
</div>
<form id="setUsername" style="display:none;">
<input type="text" id="username" />
<input type="submit" value="That's me!" />
<span id="cancelChangeUsername">| <a href="javascript:;" class="cancel" id="">cancel</a></span>
</form>
</div>
<div id="placeholder"></div>
</div>
<style>
@import url(http://cdn.last.fm/opensocial/main.5.css);
@import url(http://cdn.last.fm/opensocial/canvas.1.css);
</style>
<script type="text/javascript" src="http://cdn.last.fm/javascript/lib/prototype.js"></script>
<script type="text/javascript" src="http://cdn.last.fm/javascript/lib/scriptaculous.js"></script>
<script type="text/javascript" src="http://cdn.last.fm/javascript/source/flashplayer_inline.js"></script>
<script type="text/javascript" src="http://cdn.last.fm/javascript/11/flashpreview.js"></script>
<script src="http://cdn.last.fm/opensocial/lfm.2.js"></script>
]]>
</Content>
</Module>
What makes this so neat? Well, the widget now has access to your profile, your friends, your activities within the Host Network.
The Container
An OpenSocial Container is any website that allows its users to select, configure, and embed OpenSocial Applications in to some part of the site, usually a profile page. The container must understand the XML file format for the applications and implement the OpenSocial Javascript API. Some OpenSocial Containers include: LinkedIn, Plaxo, and Orkut. For the purposes of this article I've broken the Container concept in to a Host Network (LinkedIn, Plaxo, Orkut), and the Container (the actual IFRAME which powers the Application).
How does it work?
The OpenSocial Container boils down quite simply to an IFRAME with the text of the <Content> element from the application's XML dumped in to the body. One difficulty for building a container is dealing with the security risks of exposing cookies set by the "Host Network" to the Application's content, since the Host is doing the embedding. To ensure privacy and a certain degree of security the Container needs to originate from a different domain name than the Host. By doing this the Host/Container (they are the same entity) trick the browser into protecting the Host cookies from the Container's (and thus the Application's) Javascript.
The Container also makes extensive use of AJAX to request data from the Host/Container. This is how the Application gets access to the profile, friendship, activities, and persistence information.
Why do this? Why should we care?
OpenSocial standardizes social networking APIs. That alone is not particularly novel. But this is Google we're talking about here. With that kind of backing and buzz this may stick. As a developer this means that you only need to learn one API to be able to build social applications. One particularly interesting aspect of the OpenSocial API is the persistence layer. Using this portion of the API a developer can, quite easily, create a full featured interactive application which is entirely self contained in a single static XML file. All of the persistence and communication is handled by the Container and the Host. Now that is cool.
If this takes off like is appears to be poised to do, then we could be in for some excitement akin to the growth and fragmentation of the early social networks; except this will be happing above the social network layer. One interesting possible side effect will be a growth in the popularity of niche social networks. OpenSocial appears to lower the castle walls of the established networks. I expect the crossover in data and user-base between networks will skyrocket as once "proprietary" profile data becomes easily moved and shared.
