|By Dare Obasanjo||
|November 6, 2007 02:45 AM EST||
Obasanjo's Carnage4Life Blog
One of the Google folks working on OpenSocial sent me a message via Facebook asking what I thought about the technical details of the recent announcements. Since my day job is working on social networking platforms for Web properties at Microsoft and I'm deeply interested in RESTful protocols, this is something I definitely have some thoughts about. Below is what started off as a private message but ended up being long enough to be its own article.
In general, I personally prefer the Facebook platform to OpenSocial. This is due to three reasons:
- There is no alternative to the deep integration into the Web site's user experience that is facilitated with FBML.
- I prefer idiomatic XML to tunneling data through Atom feeds in ways that [in my opinion] add unnecessary cruft.
- The Facebook APIs encourage developers to build social and item relationship graphs within their application while the OpenSocial seems only concerned with developers stuffing data in key/value pairs.
Given the varying features and user interface choices in social networking sites, it is unsurprising that there is no rich mechanism specified for adding entry points to the application into the container sites user interface. However it is surprising that no user interface hooks are specified at all. This is surprising given that there are some common metaphors in social networking sites (e.g., a profile page, a friends list, etc) which can be interacted with in a standard way. It is also shocking that Google attacked Facebook's use of "proprietary markup" only to not even ship an equivalent feature.
The People and Friends Data API
The People and Friends Data API is used to retrieve information about a user or the user's friends as an Atom feed. Each user is represented as an atom:entry which is a PersonKind (which should not be confused with an Atom person construct). It is expected that the URL structure for accessing people and friends feeds will be of the form http://<domain>/feeds/people/<userid> and http://<domain>/feeds/people/<userid>/friends, respectively.
Compare the following response to a request for a user's information using OpenSocial with the equivalent Facebook API call response.
<entry xmlns='http://www.w3.org/2005/Atom' xmlns:georss=
<link rel='thumbnail' type='image/*'
<link rel='alternate' type='text/html'
<gd:extendedProperty name='lang' value='en-US'/>
Below is what the above information would look like if returned by Facebook's users.getInfo method:<users_getInfo_response xmlns="http://api.facebook.com/1.0/"
I've already mentioned that I prefer idiomatic XML to tunneling data through Atom feeds. Comparing the readability of both examples should explain why.
The Activities Data API
A number of social networking sites now provide a feature which enables users to see the recent activities of members of their social network in an activity stream. The Facebook news feed, Orkut's updates from your friends, and the Windows Live Spaces what's new page are all examples of this feature. The OpenSocial Activities Data API provides a mechanism for OpenSocial applications to access and update this activity stream as an Atom feed. All of the users activities or all activities from a specific application can be accessed using URIs of the form http://<domain>/activities/feeds/activities/user/<userID> and http://<domain>/activities/feeds/activities/user/<userID>/source/<sourceID>, respectively.
Currently there is no reference documentation on this API. My assumption is that since Orkut is the only OpenSocial site that supports this feature, it is difficult to produce a spec that will work for other services without it being a verbatim description of Orkut's implementation.
There are some notes on how Orkut attempts to prevent applications from spamming a user's activity stream. For one, applications are only allowed to update the activity stream for their source directly instead of the activity stream for the user. I assume that Google applies some filter to the union of all the source-specific activity streams before generating the user's activity feed to eliminate spam. Secondly, applications are monitored to see if they post too many messages to the activity stream or if they post promotional messages instead of the user's activities to the stream. All of this makes it seem difficult to see how one could specify the behavior of this API and feature set reliably for a diverse set of social networking sites.
The Persistence Data API
The OpenSocial Persistence API allows applications to store and retrieve key<->value pairs that are either user-specific or are global to the application. An example of the former is a listing of company name and stock ticker pairs, while an example of the latter is a user's stock portfolio. The feed of global key<->value pairs for an application can be accessed at a URL of the form http://<domain>/feeds/apps/<appID>/persistence/global for the entire feed and http://<domain>/feeds/apps/<appID>/persistence/global/<key> if seeking a particular key<->value pair. User-specific key<->value pairs are available at the URL of the form http://<domain>/feeds/apps/<appID>/persistence/<userID>/instance/<instan....
However, I will add that an Atom feed seems like a horrible representation for a list of key<->value pairs. It's so bad that the documentation doesn't provide an example of such a feed.
Hosting OpenSocial Applications
The documentation on hosting OpenSocial applications implies that any site that can host Google gadgets can also host OpenSocial applications. In practice, it means that any site that you can place a <script> element on can point to a gadget and thus render it. Whether the application will actually work will depend on whether the hosting service has actually implemented the OpenSocial Service Provider Interface (SPI).
Unfortunately, the documentation on implementing the OpenSocial SPI is missing in action. From the Google site:
To host OpenSocial apps, your website must support the SPI side of the OpenSocial APIs. Usually your SPI will connect to your own social network, so that an OpenSocial app added to your website automatically uses your site's data. However, it is possible to use data from another social network as well, should you prefer. Soon, we will provide a development kit with documentation and code to better support OpenSocial websites, along with a sample sandbox which implements the OpenSocial SPI using in-memory storage. The SPI implements:
- Adding and removing friends Adding and removing apps
- Storing activities Retrieving activity streams for self and friends
- Storing and retrieving per-app and per-app-per-user data
The OpenSocial website development kit will include full SPI documentation. It will provide open source reference implementations for both client and server components.
I assume that the meat of the OpenSocial SPI documentation is just more detailed rules about how to implement the REST APIs described above. The interesting bits will likely be the reference implementations of the API which will likely become the de facto standard implementations instead of encouraging dozens of buggy incompatible versions of the OpenSocial API to bloom.
|OpenSocial 11/06/07 04:53:58 AM EST|
nothing more than another networking service that is consumed by multiple web application
|bugzpodder 11/05/07 10:58:33 AM EST|
Excellent post! Thank you!
Feb. 10, 2016 09:00 PM EST
Feb. 10, 2016 02:30 PM EST Reads: 425
Feb. 10, 2016 02:30 PM EST Reads: 394
Feb. 10, 2016 01:15 PM EST
Feb. 10, 2016 12:15 PM EST Reads: 425
Feb. 10, 2016 12:00 PM EST Reads: 620
Feb. 10, 2016 11:00 AM EST Reads: 190
Feb. 10, 2016 10:45 AM EST Reads: 249
Feb. 10, 2016 10:45 AM EST Reads: 108
Feb. 10, 2016 10:30 AM EST Reads: 223
Feb. 10, 2016 09:00 AM EST Reads: 386
Feb. 10, 2016 09:00 AM EST Reads: 186
Feb. 10, 2016 08:00 AM EST
Feb. 10, 2016 07:45 AM EST Reads: 439
Feb. 10, 2016 07:00 AM EST
Feb. 10, 2016 12:45 AM EST Reads: 205
Feb. 10, 2016 12:00 AM EST Reads: 218
Feb. 9, 2016 07:45 AM EST Reads: 108
Feb. 6, 2016 03:30 PM EST Reads: 768
Feb. 5, 2016 09:00 PM EST Reads: 830