Blogs

Last week Google announced OpenSocial with an impressive set of partners including Orkut (as expected), MySpace, iLike, Flixter, Oracle, .... There were companies that had their own social network, others that offered applications through the Internet and even companies that provide services and infrastructures. There's been a lot of blogging about whether this is Google's checkmate to Facebook platforms or it doesn't make such a difference, among other reasons because Facebook could actually jump in into OpenSocial too.

But I'm not that interested in politics. What I really care about is the technical side of OpenSocial and looking at that side there are a lot of things to be excited about.

“OpenSocial is a set of APIs that an application can use to access social network related functionality. Including accessing information about the user and his/her network of friends, modifying this information or generating activities based on what the user does in the application that his/her friends will receive.”

This API is targeted to applications that run in social networks. Those applications do not usually run by themselves but are accessed through a social network container that executes it either locally (as it's done with portlets) or remotely (as happens with Google gadgets). The fact that the application runs in a web page that acts as a container is key to understand OpenSocial.

OpenSocial provides both a web services API and a JavaScript API, but it's the latter the one that makes a difference. The reason for this is that it allows the paradigm of:

var req = opensocial.newDataRequest();
req.add(req.newFetchPersonRequest('VIEWER'), 'viewer');
req.add(req.newFetchPersonRequest('OWNER'), 'owner');
req.add(req.newFetchPeopleRequest('OWNER_FRIENDS'), 'ownerFriends');
req.send(function(data) {
   viewer = dataResponse.get('viewer').getData();
   owner = dataResponse.get('owner').getData();
   ownerFriends = dataResponse.get('ownerFriends').getData().asArray() || [];
}

• The access to the API starts through an object called 'opensocial'. That object is not part of the application, it just assums that it's going to exist when it's executed within the social network container.
• Each opensocial request contains several petitions for functionality. That allows reducing latency and network bandwith, because each application only needs to make one remote request.
• The request is asynchronous (uses AJAX), so the user can interact with the parts of the site that do not need to wait for the response.

This application can be run in any web page that offers a JavaScript object called 'opensocial' that implements the functionality defined. So any current (social network) platform that already provides that functionality through it's own mechanisms and API can quite easily write a thin JavaScript and web services layer to support OpenSocial.

From an application developer perspective that really means that they can develop their social application once and deploy it in several distinct containers. The application will use the social network of the container where it's deployed.

• People Data API: access the owner of the page, the viewer and their friends
• Persistence Data API: simple storage of information about the users.
• Activities Data API: Like Facebook's mini-feed

While those modules cover much of the functionality needed in social networks, it doesn't cover all. Because the truth is no fixed standard will never be able to cover the functionality that is very specific for a given social network. So, faced with this situation what should an OpenSocial application developer do? I see two options:

1. In some cases it should be possible to leverage the dynamicity of JavaScript to check if a given functionality is available or not. And if not, just avoid using it.
2. In more complex cases, where using the functionality or not makes a bigger difference or when it has to be decided in the client side, there might be a need to create different versions of the application for each platform.

When the second option is chosen, the sentence “Develop once, run everywhere” is not true anymore. For this reason, some say that Google is not that ambitious and they are in fact promoting an slightly different motto:

Which is still quite useful. There is still one more technical aspect that may make the developer decide to have different versions per platform: the technology used to develop the OpenSocial application itself.

If you read the OpenSocial website, it clearly says that it's built on top of the Google Gadgets technology. One nice aspect about Gadgets is that the can run in one server (such as Google's servers) but can be shown in any website (for example in Liferay using the Gadget's portlet). Also Gadgets already make heavy use of JavaScript, and even have a mechanism to specify that a certain JavaScript functionality is required by the application. OpenSocial has reused that, so that if an Google Gadget wants to have the 'opensocial' object available it just needs to add the following in its XML definition:

<Require module=”opensocial-0.5”>

So using OpenSocial within Google Gadgets is easy. But Google Gadgets are not the best solution for any type of application. So the question is, would it be possible to use OpenSocial with other technologies such as portlets?

Liferay already provides basic functionality that can be used (and has been used) to build social networks. To be fair, that requires some development. For this reason, we had talked lately about developing and adding more functionality tipicaly of social networks in the default distribution (or as an official plugin).

Open Social makes this idea even more attractive. First Liferay would become one of the first products for executing open social applications (right now there are platforms, but you cannot download and use them yourself). Second, Liferay's social features would be exposed through an standard well known API, which is very useful to promote the development of extra applications that leverage it. Third, as Liferay already supports Gadgets, any open social application developed with this technology may even run unmodified in Liferay.

Although OpenSocial is a very promising technology, and I think it is big step forward in interoperation of applications in different platforms, not everything is good news for it. Most complains come from the lack of documentation and because of some security deficiencies. In fact, very shortly after it was announced someone found a way to hack an OpenSocial application and very shortly after, the same guy hacked another one. There are other people complaining about general security issues regarding the usage of JavaScript and Iframes (specially when cookies are used). And some highlight the lack of user authentication in the standard.

Other complains, that I heard in last week's W-JAX have come from people that don't like the technologies chosen and in particular JavaScript. The good news for those is that other RIA technologies such as Flash or JavaFX can also be used, since they have (or will have) connectors to JavaScript.

To be fair, this is version 0.5 of OpenSocial and the engineers behind it are showing a lot of interest in hearing what the community has to say. I'm pretty sure these problems will be solved for version 1.0. Until then it should probably not be used in live environments, but this is a great time to start development around it. We will most probably do it :)