First looks at OpenSocial: part 4 (content for persistence data)

Earlier postings:

I didn’t have time to look at the OpenSocial API yesterday, so I’m continuing today looking at the data format for the last major area, persistence data.

A vision thing?

My first impression of the persistence data API is that it doesn’t belong in v.1 of OpenSocial — unlike the member/friends and activities APIs, it doesn’t seem to be solving a core problem for social-site app writers (I have no way to get at a friends list except through the site’s API, but I can store my own data, thanks). I can see only two reasons that it’s here, neither of them very admirable:

  1. Because someone has a vision of a world where people can write social apps that run entirely on the client side with HTML/CSS/JavaScript, using only resources provided by the social site itself.
  2. Because the GData group in Google co-opted the designers to promote GData in the spec, the same way that the Blu-Ray group in Sony co-opted the PS3 to advance their agenda.

I’ll give Google the benefit of a doubt and assume that it’s a vision thing, but that’s still very unhealthy — specs should solve the real problems of the present, not the speculative problems of the future, especially bare-bones v.1 specs like this.

The format

Now that that’s out of my system, let’s take a look at what you get back from a URL like http://{DOMAIN}/feeds/apps/{appId}/persistence/global (and its many variants). From the spec, here’s what you get when you request a single piece of information from the API:

<entry xmlns=''>
<title type="text">somekey</title>
<content type="text">somevalue</content>

Or, in non-XML terms,

$globals{'somekey'} = 'somevalue'

That comes from a URL like http://{DOMAIN}/feeds/apps/{appId}/persistence/global/somekey which requests a single value. Using the first URL mentioned gets you a feed of name=value pairs, sort-of like an associative array:

<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns=''>
<link rel='' type='application/atom+xml'
<link rel='' type='application/atom+xml'
<link rel='self' type='application/atom+xml'
<generator version='1.0' uri='/feeds'>Orkut</generator>
  <link rel='self' type='application/atom+xml'
  <link rel='edit' type='application/atom+xml'

There’s only one entry in the spec’s example, but there could be a lot more. Basically, this is the equivalent of something like

$globals = { 'somekey' => 'somevalue' }

The comparison isn’t quite fair, because there are also some links explaining what you can do to modify this information, etc., but it still seems like a lot of markup for not much value (pun intended). I wonder if this would be a good place to use JSON instead of Atom+XML? After all, the serious apps will be doing their own data storage anyway, and the client-only apps will probably use a JavaScript API that hides the Atom from the developer.


As hinted at, at least, in my URL posting, there are several different data scopes:

  • All (global) data for this application on this social site (equivalent of static global variables?).
  • Data for this instance of the application only (equivalent of local or object variables?).
  • Data for this user in this application (i.e. your own profile info about the user, available every time your app runs).
  • Data for this user’s friends in this application (i.e. your own profile info about the friends, available every time your app runs).

It seems like a reasonable division of scope, especially since the app can’t get anything out that it didn’t put in.

Final thought (for now)

I do believe that, eventually, many web apps will be about to outsource storage as a service instead of having to maintain their own databases and database clusters — in fact, Amazon’s S3 and its competitors already provide precisely this service, though they might not be optimized for a lot of name=value look ups. I’m surprised though, that this could be considered a key feature of a social app spec, when so much else was left out.

This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

5 Responses to First looks at OpenSocial: part 4 (content for persistence data)

  1. John Cowan says:

    Why is #1 not admirable? (I see why #2 wouldn’t be.)

  2. david says:

    As I explained after the list, I think the vision thing is very unhealthy for specs, especially v.1 specs — it’s much better to concentrate on real problems of the present than speculative problems of the future.

  3. Lance Lavandowska says:

    I’d read someone else talk about how GData is a bastardization (my word) of Atom, but I haven’t ever looked at GData myself. If this is at all indicative of the rest of GData, I am very disappointed in Google. They should have created their own XML schemas, or used RDF/XML instead. Your earlier posts contained some puzzling usage of Atom, but this is just plain obscene.

  4. Brendan says:

    How about a third idea, that you could “submit” your app to the OpenSocial container and it would run entirely server-side? Then it would obviously need some persistent storage somewhere, and you might as well use a shared protocol… if Google et al are thinking like this, it starts to make more sense.

    I agree that the protocol is very bloated, but even this isn’t quite as much of an issue if most of the network chatter is local to the OpenSocial container.

  5. david says:

    Brendan: I’ve been thinking along the same lines. They’ve already gone part-way there with GData, and hosting apps isn’t that different from hosting videos on YouTube — it’s something that most amateurs couldn’t manage.

Comments are closed.