Aehso’s Output

Three recent posts on OpenSocial that I’ve come across that all touch on points I raised in my last two posts that are worth sharing:

• Terms (Shelley Powers) – comments on the very important issue of the terms and conditions attached to usage of the OpenSocial APIs – I had completely overlooked this. T&C are normally attached to proprietary products, not open standards. So it looks like we are really looking at Google APIs, not open standards here.
• Where the hell is the Container API? (Russell Beattie). Short, to the point, and bang on the money. I’m not in a rush so I’m happy to wait for important web API specifications to be drafted, discussed, refined, voted upon and published via a credible authority. But the OpenSocial development process is not open (a newsgroup of pleading users does not make it so).
• Google OpenSocial: Technical Overview and Critique – Dare Obasanjo. Too much to summarize here, go read it.

All in all I’m beginning to think the use of the term Open in OpenSocial is terribly misleading marketing speak. I’d like to think this is an accident (after all Google care about the continued growth of an open internet right?) but there is such a monstrous gap in the process behind and the function of OpenSocial and how other open APIs and standards are developed that I can only assume that this is all a marketing exercise to misdirect attention away from Facebook at the cost of ushering out a half-baked alternative. The Campfire One video only re-enforces this – it is incredibly corny and lacking in substance!

APIs and standards are sometimes hacked together by partnerships in order to try address immediate market share concerns – this is beginning to look like yet another of these efforts. Hopefully I’ll be proven wrong when the Container API documentation is published but I’m not holding my breath…

aehso google, opensocial, social, widgets

Authentication

Update: Miron highlights another potentially critical problem – track it here

I hinted that authentication was a concern at the end of my previous post on the topic.

According to the OpenSocial documentation I can only surmise that the only authentication mechanisms prescribed by OpenSocial are the Google Authentication APIs. The application user gets redirected to Google Login and once done the application gets a token that it uses when calling the OpenSocial APIs. This implies that every OpenSocial application user has to have a Google Account.

There are no references to open alternatives such as OAuth or OpenID in the documentation. It’s worth bearing in mind that the existing documents are very Orkut centric so perhaps they are focusing too much on explaining how it works within the Google/Orkut world but I can’t find any alternative info. This really doesn’t seem very Open!

I’m wondering how this this will work for applications that they are deployed into Ning or MySpace. Do the application have to detect that it is not in Google-land and use the local container’s authentication/delegating authority mechanism? Or do they continue to authenticate against Google Accounts? Am I missing something obvious here?

Hosting
Here things get fuzzier. One of the main things I wanted to find out was how I might host an OpenSocial application on our servers, in the same way that we host some of the Facebook applications that we have developed for clients. (Facebook authentication is described here for those are curious about where I’m coming from here)
The docs only talk about Google Gadgets. There isn’t any reference a callback API that the OpenSocial container calls when it wants the content for the application – this concept doesn’t seem to exist (or at least is not documented). The AuthSubRequest API does take a next parameter but is that it?

Applications
Here things even fuzzier. Again the Open Social docs are very Google-land centric so all they talk about is Google Gadget based social applications. I initially thought that they were just using Google Gadgets to illustrate how JavaScript based widgets would interact with the OpenSocial APIs but then I noticed that the OpenSocial home page states:

OpenSocial is built upon Google Gadget technology, so you can build a great, viral social app with little to no serving costs.

Uh-oh. Why create a dependency between an open social network API and a proprietary widget platform? I can see that some OpenSocial applications might be built as Google Gadgets but what if I want to create an OpenSocial application that isn’t?

Update: Simon Willison has some similar concerns and questions.

aehso facebook, google, opensocial

Starting to read through the OpenSocial API documentation the most striking feature is that ALL of the underlying data APIs are Atom and AtomPub based.

• The People Data API exposes people (viewer, owner, friends) via Atom feed documents and Atom entry documents. However, there is no AtomPub support for this feed so people cannot be created/updated/deleted via API. I suspect this will cause some debate as it means some fairly critical data remains locked into the underlying OpenSocial containers
• The Activities Data API exposes activities (news feeds etc) as a Atom feeds. The Activities data feed can be fully manipulated (CRUD) via Atom/AtomPub requests.
• The Persistence Data API exposes name/value pair data (e.g. configuration params) as a Atom feeds. The persistence data feed can be fully manipulated (CRUD) via Atom/AtomPub requests.

I’m off for a curry but more later today. Here’s a teaser though – authentication is a concern….

aehso api, app, atom, atompub, google, opensocial, social