Scott's Workblog

This blog has moved! Go to my new blog!

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:

GET http://{domain}/feeds/people/{person-id}/friends

Rather than the API simply declaring the JavaScript method:

Widget.getFriends(Callback object)

and possibly:

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.

However, this really needs to be pulled out from the Gadget API aspect as it isn't exactly a sensible way of making a Widget work - a Widget container should know which Widget is calling it and whether its authenticated, so retrieving a list of friends should be a trivial JavaScript call to the main Widget API and should not need a special HTTP request to be constructed by the Gadget.

3. Activities

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(Callback object)
Widget.getActivities(String source, Callback object)

...would work just as well?

4. Persistence

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

5. Authentication

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.

Summing up

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.

Two steps forwards, one step back. This is not a great leap forwards for Widget technologies - if anything the news is generally negative. But its a great leap forward in terms of a group of social networking sites providing some open endpoints in a fairly standard way. Perhaps eventually these can be mapped onto a sensible JavaScript API within a truly open Widget specification

main archive