Last week, the major news on the Web was the launch of OpenSocial. Google did an excellent job documenting APIs and publishing quick-start tutorials and videos, as well as signing-up an impressive group of early adopters. All that is left to us, the blogger by-standers, is to review, envy and criticize. That is exactly what we are going to do.

Since it’s too early, I, personally have only a few, quick comments. These comments may be totally off, so I insist on the right to change my statement at-will. Nevertheless, the first impression of OpenSocial is highly positive. The API is clear, concise and pragmatic. Pragmatism and (at least an attempt of) parsimony are a necessary feature for such API. It seems like Google is on the right track on that front.

Some of our readership, coming from the Java/J2EE world, may draw parallels between OpenSocial and Java Portlets API (JSR-168). Java Portlets API was created about four years ago, intended to be a plugin infrastructure for Java-based web sites (a plan much less ambitious than that of OpenSocial) and - failed miserably. The main reason why it failed was that it was too restrictive in the areas that do not matter, and too general in the areas they should have described in detail. Areas like user profile management, user actions, user interactions. Basically, JSR-168 was page-centric, rather than user-centric and the demand is for a user-centric integration. Rendering is a job of a container.

OpenSocial has clearly avoided the trap that JSR-168 fell into. They concentrate on the right features: people, activities, persistence. The choice of the platform - Javascript, REST (bye-bye SOAP), Atom, RSS, HTML and CSS makes complete sense. The API is quite modular, reasonably high-level and what seems like flexible-enough to allow for all kinds of applications. We were shown some very different applications in the demos, created by different vendors.

Now that we have praised OpenSocial enough, and probably nobody had any doubt in its huge potential, anyway, let’s mention some oddities, we’ve noticed:

  1. Quickly scanning through the API, we could not find any direct support for internationalization. The ultimate API for social networks, without a strong support for transparent, easy translation mechanism?
  2. The API, whilst clean and lean, is very conservative in its architecture. Not that it’s wrong or bloated, but it’s too straightforward. Let’s use an analogy to explain what we mean. There are many Ajax-based libraries. Out of these, jQuery stands out like a rock-star. Not only it gets job done, and gets it done well, but it has a unique, elegantly revolutionary approach that none of the other libraries have (not even Google’s own GWT). When you look at an API that is supposed to change the reality on the Web, you do kindof expect the design to be revolutionary as well. Not safe, correct and conservative, but - leaping in the future. Well, maybe I am too much of a geek and just complaining, but I do think there’re enough of other code-purists that would agree.