Earlier postings:
This is the third part of a series where I’m working through the OpenSocial specs as I write — that means that I haven’t preread and predigested this stuff, but am creating a record of how I approach a new set of specifications and try to understand them. First, I looked at the basic URLs for data access, since they provide the best high-level description of the OpenSocial capabilities (read-only info on members and their friends, read/write info on a member’s activity notifications, and a simple data-storage API). Next, I looked at the data format for the most important content, the member profile and friends lists. This time, I’ll look at the format for activity notifications, which is also based on the Atom syndication format.
Activities
To get a list of a member’s recent activities (uploaded a photo, poked a friend, got a new job, or stuff like that, I guess) an OpenSocial application uses the URL pattern http://{DOMAIN}/activities/feeds/activities/user/{userId} according to the specs, though I suspect that might be intended to be http://{DOMAIN}/feeds/activities/user/{userId} for consistency with the other data-access URLs — it’s hard to be certain. The host should return an Atom feed of activities, like this template example lifted from the spec:
<atom:feed xmlns:atom='http://www.w3.org/2005/Atom'
xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/'
xmlns:gact='http://schemas.google.com/activities/2007'>
<atom:id>http://www.google.com/activities/feeds/activities/user/userID/source/sourceID</atom:id>
<atom:updated>1970-01-01T00:00:00.000Z</atom:updated>
<atom:category scheme='http://schemas.google.com/g/2005#kind'
term='http://schemas.google.com/activities/2007#activity'/>
<atom:title>Feed title</atom:title>
<atom:link rel='alternate' type='text/html' href='http://sourceID.com/123'/>
<atom:link rel='http://schemas.google.com/g/2005#feed'
type='application/atom+xml'
href='http://www.google.com/activities/feeds/activities/user/userID/source/sourceID'/>
<atom:link rel='http://schemas.google.com/g/2005#post'
type='application/atom+xml'
href='http://www.google.com/activities/feeds/activities/user/userID/source/sourceID'/>
<atom:link rel='self' type='application/atom+xml'
href='http://www.google.com/activities/feeds/activities/user/userID/source/sourceID'/>
<atom:author>
<atom:name>unknown</atom:name>
</atom:author>
<openSearch:totalResults>1</openSearch:totalResults>
<openSearch:startIndex>1</openSearch:startIndex>
<openSearch:itemsPerPage>25</openSearch:itemsPerPage>
<atom:entry>
<atom:id>http://www.google.com/activities/feeds/activities/user/userID/source/sourceID/a1</atom:id>
<atom:updated>2007-10-27T19:41:51.574Z</atom:updated>
<atom:category scheme='http://schemas.google.com/g/2005#kind'
term='http://schemas.google.com/activities/2007#activity'/>
<atom:title>Activity title</atom:title>
<atom:link rel='self' type='application/atom+xml'
href='http://www.google.com/activities/feeds/activities/user/userID/source/sourceID/a1'/>
<atom:link rel='edit' type='application/atom+xml'
href='http://www.google.com/activities/feeds/activities/user/userID/source/sourceID/a1'/>
<gact:received>2007-10-27T19:41:51.478Z</gact:received>
</atom:entry>
</atom:feed>
There’s a lot of front-matter in this, so it’s hard to realize at first glance that it lists only a single activity (in the atom:entry element near the bottom). The entry itself uses mostly standard Atom elements, except for one extension element from the Google activities namespace, giving the date that the notification was received (received date is also important in the news industry, so maybe this is something Atom needs to add to its core). Other than that, the activity itself is easy enough to understand: it has a unique id, a couple of dates, a title (which seems also to serve as the sole description), and web links for viewing and editing.
Unlike the member and friends info, which was read-only, OpenSocial allows apps to post new activities and edit or delete existing ones, but only in what is called a “source-level feed” — that’s a list of a user’s activities limited to a single source (which, I assume, is the application), using the URL pattern http://{DOMAIN}/activities/feeds/activities/user/{userId}/source/{sourceId} (which, again, may be a typo with an extra “activities” path element at the beginning). In other words, an application can read activities from any source, but it can mess around only with the ones it created. I’m not sure yet how the application knows its source id, or how the host verifies the app’s identity, but I’ll be looking at those issues in a later posting.
For members and friends, I noted that the spec’s example included the OpenSearch namespace but didn’t use it. This time, the namespace is used for the totalResults, startIndex, and itemsPerPage elements. These suggest that it’s possible to page through long lists of activities, though I could find no mention of that in the spec. Again, I don’t know much about Atom, but I think that Atom-blessed way to handle paging would involve using “first”, “next”, and “last” links.
Still learning
I’m not deeply into social networking myself — with my adolescent children using Facebook, my joining that site would be like showing up in a leather jacket at their highschool dance, and 99% of the time I spend on the more grown-up sites like Plaxo, LinkedIn, and Dopplr is used approving connection requests. As a result, I wasn’t aware of how important activity notifications were for a social-networking site.
Whatever happens with OpenSocial, I have found it to be a good architectural introduction to social networking in 2007, though I suspect that the next thing I’m going to look at — the persistence data API — has more to do with Google’s business requirements than with social networking itself.
Quoderat 