Shonzilla, a pattern-seeking animal

A discussion recently started by Harry Hübner and commented by Christopher Blum in OpenSocial Interest Group I’m moderating over at XING, led me to a conclusion:
Supporting various applications (either web 2.0 or headless server functionality) inside an OpenSocial container can create more traffic (and revenue if they’re commercial) for application’s developers.

Here’s my attempt to stand on Christopher’s shoulders and go into more detail. His proposition of “OpenSocial interoperability” by bringing various popular [web 2.0, headless] applications into OpenSocial containers is one of the ways to get more traction and traffic by using OpenSocial, which in turn could improve perceived interoperability.

This kind of interoperability can be best achieved using OpenSocial REST API which enables application’s home server to access selected OpenSocial container functionality. In this case, best-of-breed and widely adopted technologies are used: HTTP protocol for invoking container’s entry points and JSON for encoding data (read or written).

BTW, headless application can be any functionality on some server that runs or can run without a UI. For some examples of headless applications consider a Jabber or IRC server. You can let your imagination run free once you realize that this headless application can also be (almost) any application running in Amazon EC3, Google App Engine and other clouds. I’m wrote “almost” in parenthesis to include only those apps that understand REST, i.e. speak HTTP and understand JSON.

1. using OpenSocial REST API to enable application’s home server read from and write into OpenSocial container to improve integration of application’s core functionality (running on server) by accessing OpenSocial data items like Person objects (e.g. users of XING, Orkut, MySpace, etc.) and AppData objects (which encapsulate all the specific object types relevant to the application’s core functionality). Using Person and AppData objects on home application’s server improves “social-awareness” of that application. Another part of this scenario is:
2. using OpenSocial Gadget XML and Gadget API to display socially-aware application’s data (accessed inside an OpenSocial gadget

Note that either part of this scenario or both 1. and 2. can be used to improve application’s interoperability.

In using part 1 of this interoperability scenario, the initiative for improving social-awareness of a popular application by using REST API to connect to OpenSocial container is in the hands of the original application’s developers. In the case of open-source application projects, there are less impediments and objective reasons not to connect open-source applications to OpenSocial container and, through it, all the users using the app. This way, data is not only more socially-aware but also more pervasive when part 2 is used.

When using part 2, application data is embedded into a “personalized web panel” running inside OpenSocial container thanks to Gadget XML, Gadget API and different features-specific APIs that are optionally supported by the respective OpenSocial container. The most interesting feature (i.e. OpenSocial JavaScript API namespace) is RPC feature (which stands for remote procedure call) that an OpenSocial container may implement (since it’s an optional API) to provide gadget-to-container, container-to-gadget, and gadget-to-gadget communication.

The final result of this interoperability scenario is better data availability and more convenience to users which can lead to an increased [web 2.0, headless] application’s usage.

The most prominent example of increased usage thanks to implementing OpenSocial (albeit implementing the entire OpenSocial container is more work than previous scenario) is Plaxo Pulse which got an order of magnitude