OpenSocial as an alternative to JSR 168
OpenSocial came onto the scene at the end of 2007 but until now I hadn't got around to delving into it and I thought it was about time.
My first observation was that its name is actually a bit of a misnomer. I expected data portability for social data, but in fact this is not what OpenSocial is about, it is instead more akin to "OpenWidget" or "OpenGadget" (as many others have pointed out). This however is not a bad thing, it is just different than what I was expecting.
OpenSocial is the expansion of Google Gadgets across platforms, with the view being that once an OpenSocial Gadget had been developed once and used on one site that it would be able to run on another social networking site and easily access friends lists and other social information on that site due to the common API that OpenSocial mandates. If this all sounds very similar to JSR 168 / 286 and the concept of Portlets then you would not be mistaken (for more on JSR 168 see my earlier post titled 'Are Portal Servers dead?'). Similarly, Netvibes tried to get some standardisation in this space with their Universal Widget API (UWA) standard but this hasn't got much (any?) traction.
I believe OpenSocial has a lot more hope than JSR 168 and other similar efforts, largely due to the weight of Google behind it, but also due to some other very big players signing up (i.e. MySpace, LinkedIn, Plaxo, SalesForce.com, Ning, Yahoo! and many more) and the standard appears to be rapidly evolving.
OpenSocial Gadgets can be considered the Web 2.0 equivalent of Portlets; they are typically more user centric than site centric, mashups tend to occur on the web client vs server side aggregation, and from a programming perspective it appears easier and more elegant. Coupled with a servlet backend OpenSocial Gadgets appear to be able to do everything a Portlet would usually be able to do, including Gadget-to-Gadget communication.
Just like Portlets require a Portal, OpenSocial Gadgets require an OpenSocial Gadget container. To start with I used iGoogle, which was very easy to add a new gadget to. I then decided that I would like to host my own OpenSocial Gadgets so I decided to try out an open source implementation from the Apache Software Foundation called Shindig. This is apparently used by a number of people but some reason I couldn't get it working for me; I suspect it has more to do with my PC than anything.
All in all, I think OpenSocial is definitely worth further investigation.
Key sites for further information:
My first observation was that its name is actually a bit of a misnomer. I expected data portability for social data, but in fact this is not what OpenSocial is about, it is instead more akin to "OpenWidget" or "OpenGadget" (as many others have pointed out). This however is not a bad thing, it is just different than what I was expecting.
OpenSocial is the expansion of Google Gadgets across platforms, with the view being that once an OpenSocial Gadget had been developed once and used on one site that it would be able to run on another social networking site and easily access friends lists and other social information on that site due to the common API that OpenSocial mandates. If this all sounds very similar to JSR 168 / 286 and the concept of Portlets then you would not be mistaken (for more on JSR 168 see my earlier post titled 'Are Portal Servers dead?'). Similarly, Netvibes tried to get some standardisation in this space with their Universal Widget API (UWA) standard but this hasn't got much (any?) traction.
I believe OpenSocial has a lot more hope than JSR 168 and other similar efforts, largely due to the weight of Google behind it, but also due to some other very big players signing up (i.e. MySpace, LinkedIn, Plaxo, SalesForce.com, Ning, Yahoo! and many more) and the standard appears to be rapidly evolving.
OpenSocial Gadgets can be considered the Web 2.0 equivalent of Portlets; they are typically more user centric than site centric, mashups tend to occur on the web client vs server side aggregation, and from a programming perspective it appears easier and more elegant. Coupled with a servlet backend OpenSocial Gadgets appear to be able to do everything a Portlet would usually be able to do, including Gadget-to-Gadget communication.
Just like Portlets require a Portal, OpenSocial Gadgets require an OpenSocial Gadget container. To start with I used iGoogle, which was very easy to add a new gadget to. I then decided that I would like to host my own OpenSocial Gadgets so I decided to try out an open source implementation from the Apache Software Foundation called Shindig. This is apparently used by a number of people but some reason I couldn't get it working for me; I suspect it has more to do with my PC than anything.
All in all, I think OpenSocial is definitely worth further investigation.
Key sites for further information:
- OpenSocial - Google Code - This is the key site for information
- Home (OpenSocial) - The official OpenSocial home page
- Architectural Overview of Shindig , an OpenSocial Reference Implementation - Excellent overview of the OpenSocial & Shindig architecture
- Shindig - an Apache incubator project for OpenSocial and gadgets - Shindig home page
I just tried the Plaxo hosted version with a few XML / URLs that are kicking around on the net and got a message saying that Plaxo need to authorise urls before they are used. In the spirit of OpenSocial, I'm not sure that the opt in model works for apps, maybe it should be allow all and deny by exception.
ReplyDeleteJust a thought! Other than that, nice post. I was looking at it last week and wondered the same thing and I'm sure this will kill off JSR168 as this is easy and, if you want, free and hosted for you.
In terms of an opt in model for apps, different Containers are handling it differently. Check out the Getting Started Guide for a table which summarises this.
ReplyDeleteThere is definitely a balance required between letting users do something that could bring down the platform or cause havoc in some way vs providing a user-centric solution where the user can do what they want.