OpenSocial is a pattern that a social network vendor can follow to expose their social network services to web app developers. OpenSocial does not actually unify services across multiple vendors. OpenSocial does not resolve differences between vendors, particularly login identity.

In the OpenSocial model, each vendor is still its own island in the sea, requiring users to create new userid/password pairs, and requiring developers to obtain the user’s login credentials for each vendor network they wish to use. If you’re a web app dev and want to tap into your user’s stuff on 6 different social networks, you’ll need to prompt your user to enter login credentials for each of those 6 vendors.
The only point of unification / convenience is for developers, in that developers may see familiar or at least similar APIs provided by different vendors supporting OpenSocial.

Since it is only a pattern, OpenSocial does not provide any guarantee of semantics across vendors. The pattern is certainly helpful as a common grammar between tribes, but having two or twenty vendors implementing the OpenSocial API pattern does not mean that you’ll be able to write one OpenSocial client and expect it to work flawlessly with all vendors. The semantics and response schemas may vary. Caveat emptor.

This is sort of like the difference between the SQL standard and using it with any particular database vendor. Most relational database engines support standard SQL queries (as well as non-standard extensions), but the steps and tools you need to use to connect to that database engine to issue SQL queries, and what data types are supported, varies with each database vendor. SQL has been very successful, but the database landscape is still a very walled garden.

Also check out Dare Obasanjo’s analysis of the OpenSocial APIs.

Share/Bookmark

Google OpenSocial has two sets of APIs: JavaScript for web pages, and ATOM / REST style APIs for server apps or “installed client” (non-browser, presumably native code) apps.

The ATOM/REST APIs are collectively called the OpenSocial Data APIs.

The OpenSocial Data APIs are broken down into three groups:

• People & Friends Data API
• Activities Data API
• Persistence Data API

All the Data APIs require user login, and the current Google documentation only discusses use of Google user accounts. I’ve found no mention of whether user logins from other domains can be used here. Frankly, I doubt it.

Of the 3 data APIs listed above, only the People & Friends API is actually up and running. The Activities and Persistence APIs are documented but not yet available.

The Google user login mechanism (AuthSub) and general model of the People & Friends API appear at first blush to be conceptually identical to the Microsoft Windows Live Contacts API (my old stomping grounds), launched in May 2007. There’s going to be a massive patent battle in this area in a few years when the patents currently in process emerge from the other end of the USPTO pipeline.

One of the biggest differences between the OpenSocial People & Friends API and the Windows Live Contacts API is that OpenSocial does not support query filters. You can’t fetch just the friends that share an attribute (like, group or tag). Windows Live Contacts API has rich query capabilities right out of the gate. (You can play with Windows Live Contacts API queries here: http://www.randomthirdparty.com/)

I found no discussion in the Google docs of how third party social systems integrate into this OpenSocial API. Do they implement the same APIs on their own domains? Or are they merged together under the Google umbrella? Not clear yet. Still digging. Stay tuned.

Share/Bookmark

The OpenSocial URL on Google still isn’t lit up yet, so we’ll just have to wait to see whether they deliver the goods or rhetoric.

Share/Bookmark