November 05, 2007
Two Steps Forwards, One Step Back: OpenSocial and open Widget technology
I thought I'd wait a little while to see how the OpenSocial thing was received; no point me writing about it when there is so much else popping up. But there are some issues I think are worth raising here: how "open" is OpenSocial? And how does it play with current standards work?
1. Packaging and portability
OpenSocial is presented (not entirely accurately, see below) as an extra API for a Google Gadget. GG is Google's proprietary Widget technology, similar to Yahoo! Konfabulator, Apple Dashboard, Microsoft Vista Gadgets, Opera Widgets and so on. W3C is currently creating a single specification for Widgets, although this is focussed on Widgets aimed at desktop platforms, it requires very little tweaking to get things working for web containers, too. For example, as part of a European project I work on we did just that ("Extending IMS Learning Design services using Widgets: Initial findings and proposed architecture.", Wilson, Sharples & Griffith (2007)).
I would have preferred OpenSocial's launch to have also been marked by a public commitment by Google to work with W3C on standardising the packaging and basic APIs for their Gadgets. As it stands, however, there is no particular reason why OpenSocial can't be retuned as an API extension to the W3C Widgets spec when its finalized.
2. Friend lists
OpenSocial does something quite strange, it uses Atom:entry for information about people. I can get the use for activities, and even "persistence" at a push. But people? Well, at least its an open standard (IETF RFC 5023). However, if you look at the mapping of elements in the reference documentation it does seem overly proprietary and a bit of a workaround; all the properties could have been more easily and sensibly mapped onto FOAF properties.
In terms of implementations, I'm actually a bit puzzled as to why the API requires packaging this HTTP request:
Widget.getFriendsOf(String user, Callback object)
It does have the advantage, not really for the API as such, of getting networks to provide a standard endpoint for requesting friend data usable by things other than Gadgets/Widgets. This is great news, even if it isn't FOAF, which we already know how to deal with and has a nice rich model.
Well, at least the Atom:entry format makes a bit more sense here. This just provides a standard Atom endpoint for sending status updates and getting status feeds. Again the question of why this needs to be an endpoint is pertinent. As from a Widget author viewpoint surely...
Widget.setActivity(String text, Callback object)
Widget.getActivities(String source, Callback object)
...would work just as well?
This is quite interesting as it mirrors to a certain extent the approach we're using in TenCompetence to enable Widgets to share data within a context declared in the container - for us this means the learning activity within which a Widget appears - for example, to support a group chat Widget or group voting Widget. For Google this is either a global context or a "friends" context, but the principle is the same. The main difference is that we basically saw the method as being a Widget API call to post and get objects serialized using JSON, rather than an Atom HTTP request
Google's authentication technology is already a big enough pain to developers using the Atom protocol for publishing blogs - everyone else uses HTTPS + HTTP Basic Auth, as its easy and secure enough for most purposes. However, you need a special piece of code just to get a GData token for posting to Blogger, and even then Google warns that your app might break as rather than returning a token it may, for some reason, send back a redirect to their Captcha page.
I'm sure Google have their reasons, but extending AuthSub and ClientLogin to other platforms seems like a step backwards, not forwards. It certainly makes little sense for systems other than Google-owned ones to implement this authentication mechanism.
On a sidenote, we really need to figure out an OpenID process that works for rich clients and plugins.
Ultimately I think that once you peek under the covers at the actual API you can see that what's here isn't actually all that big a deal. We have an API that a Google Gadget can use to get a list of friends (as an Atom feed). We have an API that a Gadget can use to post a status update entry. We have an API that a Google Gadget can use to store Atom entries.
These are actually not terribly dependent on the Google Gadget technology that is being used to wrap up the methods. Why this has happened is vaguely understandable in terms of getting the container-application relationship working with Orkut, but it does come across as an "embrace and extend" move pitched against the W3C effort. Which is a shame as its the best thing W3C have done in years.