playing OpenSocial - in your own sandbox


2008-6-13

Google's OpenSocial spec and stack of technologies has been my main focus of the last few days. I'm investigating several things:

So, what IS OpenSocial?

Quick answer: a 'standardized' way to write 'gadgets'. Little widgety small apps that 'live' on your profile or personal homepage INSIDE a social networking site. (I'll get to the all caps inside in a sec)

So OpenSocial really is a 'format' for developers to write smallish apps, that user's can then place on their profiles. regadless if they are using MySpace, hi5, Blogger or ANY other SNS - that supports OpenSocial (it is then called an OpenSocial 'container'.)

It does this by exposing certain social data in an unified way to the gadget JavaScript - regardless of which container it is hosted in. In theory the write once rin anywhere thing.

What can an OpenSocial gadget do?

Hmmm, good question :) The OpenSocial API (which is a JavaScript API) enables the hosting social network site to expose certain social data to the gadget. The key here is 'certain data'. From the OpenSocial pov there are mainly Persons, Relations between Persons, and Activities. And then there is 'App Data' which really means 'anything you can store as a key/value pair'... and people have been majorly creative here by storing JSON-yfied data structures etc.

One of the main limitations here (apart from what data is available in the first place) is what the API allows to write. Most of this data is read-only.

OpenSocial knows these kinds of Person: VIEWER and OWNER. The VIEWER is the one (SNS member) who is viewing the page the gadget is on. The OWNER would be the person on who's (profile etc) page the gadget is 'installed'... and then there are VIEWER_FRIENDS and OWNER_FRIENDS (and possibly friends of friends). Now the gadget can read (and display) social data about all these Persons... but it can ONLY write the VIEWER's data, and even that in a rather limited fashion. See these bits of the OpenSocial tutorial for some entertaining hacking of how to work around that limitation:

Adding the ability to see what others have sent you isn't too difficult, but it does involve a bit of a trick. Currently an application can only write to the persistent storage of the viewer of the gadget, so this gadget stores all the gifts you've given in the 'gifts' field of the viewer's application data. When one of your friends views her instance of the gadget, the gadget will have to seek out the gifts that she has received by checking the 'gifts' field of each of her friends. In short, you can only write to your own storage, but you can read the application data of your friends (as long as they have the app installed, too).

The IFrame is back

One of the big suprises for W3C evangelists and those who comply to their teachings is this: Gadgets, like many widgety things, live in IFRAMEs. And there is a good reason for that: Security. Let me quote (one of) the author(s) of Shindig:

By the gadget and the site being on different domains, the browser blocks all interaction between the two, so the gadget can’t do anything to your site (such as spamming, stealing passwords or financial info, or virus like activities like auto-adding friends, and so on).

What's that 'container' thing then?

Another important aspect - at least for my work - is the fact that an OpenSocial gadget can initially only access and use social data from the SNS it is hosted in - the OpenSocial container. So I can write ine gadget spec file, and people can install the gadget on any of their favourite places - Their hi5 profile page, on their iGoogle homepage, etc etc.

The app server thing

But wait - there is more. In addition to accessing the OpenSocial API that the container exposes, any gadget can also access and communicate with an outside app server. There are security protocols in place to secure this communication, this is where OAuth (specifically only a subset of it) comes in btw.

With this secure communication to an app server the gadget could do most anything. The OpenSocial API and container supply the user info and social data, the external app server does anything else. But this is also where the wormholes start to show - and where it becomes a trust thing. Do OpenSocial containers (SNS hosters) 'trust' gadgets that communicate with an outside app server? (Containers can limit what gadgets users can put on their pages.) Do users trust these gadgets?

What about that sandbox thing you mentioned?

After that overview of sorts, here's some practical info. For a developer of any of these mentioned parts, it's not practical to develop in any one of the big SNS OpenSocial containers. (If you want to do that, there's a nice list of systems and their capabilities in the Google GettingStartedGuide.)

More intersting would be to actualy set up an OpenSocial container of your own, and possibly even turn your favourite (or own) SNS project into an OpenSocial container. That's perfectly possible, and here is how, thanks to the Apache Foundation:

  • Part One: We need a 'Gadget Renderer', an implementation of the OpenSocial APIs etc.The Apache Foundation has a project called Shindig that does just that. It has a Java and a PHP implementation, so it should work for many.
  • Part Two: a SNS that we can hook up to this, and that will 'host' the gadgets. In my case this will eventually be the PeopleAggregator.net system, but to get started and to see how the communication between the parts works, I strongly recommend trying out the sister project to Shindig, Partuza. It's not much of an SNS to write home about, but it has all the data and notions we'll need to expose later. And if you get these two set up correctly you have a system where you can see how it should work... before you plunge into hacking blindly ;)
  • usefull guides to setting up shindig and partuza (the official ones are a bit out of date and refer to files and folder structures that have changed): shindig_install/, partuza_install/

So what's the rub?

As you might guess I'm not investigating all this just because. My task is and was to find ways to use this new and evolving tech to further enable the PeopleAggregator platform and to offer compelling solution to our clients. So, what's in it for them?

  • turning PeopleAggregator into an OpenSocial container - this would allow PA users (and users of any system/network based on PA) to place any OpenSocial gadget they choose on their PA pages. This is a 'nice to have' feature.
  • writing custom OpenSocial gadgets. As tempting as this technology is, that's not the core competence or offering of BBM.
  • writing OpenSocial gadgets that use another (PA based) SNS as their app server.... now this might be interesting!

Oh, did I mention Google Friend Connect?

Now how does that fit into all this? Well, Google Friend Connect is an interesting beast, from what I've seen after accessing the preview program. Mainly it's a widgety thingy that any site owner can place on their site... and have instant SNS capabilities. Comments, Reviews, membership, friends, the lot. Most importantly GFC is an OpenSocial container, so you can include any OpenSocial gadget in it, and thus on any website.

Now if you count one and one and then some together, you may see where my thinking is headed here ;)

Also, Google Freind Connect as an SNS has some interesing cross-SNS capablities like inviting in friends from other systems etc. As such GFC could possibly be a nice 'Hub' of sorts...

Similar

<< ambience  |  back up, but not from backup >>

alles Bild, Text und Tonmaterial ist © Martin Spernau, Verwendung und Reproduktion erfordert die Zustimmung des Authors

Martin Spernau
© 1994-2024


amazon.de Wunschliste

Facebook me!
Google+

Google

powered by Traumtank