Gerüchte über „das grosse Ding“, was Google plant, gibt es ja schon etwas länger, sie reichten ja sogar aus, um Google Pläne für einen Second Life-Competitor unterzuschieben. Das war es aber nun doch nicht ;-) Statt dessen hat Google Ende letzter Woche eine neue API namens OpenSocial angekündigt.
Was ist Open Social?
Auf Facebook sind sie ja sehr beliebt: Applikationen, die von verschiedensten Leuten für die Facebook-Platform geschrieben werden. Das Problem ist aber, dass diese Applikationen auch nur auf Facebook laufen und sonst nirgends, da allerlei proprietäre Schnittstellen und Formate verwendet werden. Dies bedeutet für Anwendungsentwickler, dass sie für jede existierende und zukünftige Plattform die Applikation anpassen oder gar neu entwickeln müssten.
Um dem entgegenzutreten, wurde dann Open Social entwickelt. Dabei war wohl Google der Initiator, hat sich aber mit verschiedenen Anbietern, wie Ning oder Six Apart zusammengetan, um die Möglichkeiten und Wünsche auszuloten. Herausgekommen ist ein Set von 3 APIs, die Applikationen benutzen können, um auf den Plattformen lauffähig zu sein, die Open Social unterstützen.
Als Beispiel nennt man gerne Flixter, was auf Orkut oder Ning oder einer anderen Plattform laufen kann:
Als Screenshot könnte es so aussehen (hier ein Ning-Netzwerk):
Man sieht also, dass das Widget auf der Ning-Seite (per iframe) eingebunden ist. In diesem Beispiel ist es nicht entsprechend gestaltet, um es deutlicher zu machen, das soll aber auch möglich sein (wobei ich mich frage, ob man dann doch verschiedene Widget-Versionen für verschiedene Sites bereitstellen muss. Zumindest muss man ja evtl. das CSS anpassen).
Die Widgets, die im Google-Jargon ja Gadgets heissen, haben dabei Zugriff auf verschiedenste Daten des unterliegenden Social Networks, wie Profildaten des Benutzers, dessen Freunde oder z.B. dessen Aktivitäten.
Wie entwickelt man eine Applikation?
Eine eigene Applikation zu entwickeln, ist prinzipiell recht einfach. Zunächst muss man sich mit der Google Gadget API beschäftigen. Heraus kommt im Prinzip eine XML-Datei. Diese kann für ein Hello World z.B. wie folgt aussehen:
<Module> <ModulePrefs title="Hello, World"> <Content type="html"> <!--[CDATA[ <br/> Hello, World<br/> ]]--> </Content> </ModulePrefs> </Module>
Wie man also sieht, besteht so ein Gadget aus beliebig viel HTML (hier nur „Hello, World“) und ein bisschen Infrastruktur. Diese Gadgets können recht einfach mit dem Google Gadget Editor geschrieben und auch bereitgestellt werden (wenn man sie auf einem Google-Server hosten will). Heraus kommt dann ein Link zum Gadget. Dieses kann dann z.B, auf iGoogle oder eben auf Plattformen, die Open Social unterstützen eingegeben werden.
Solch ein Gadget hat dann aber noch keinen Zugriff auf irgendwelche Daten des unterliegenden Netzwerkes, sondern ist sozusagen self-contained. Um nun die Open Social-API zu aktivieren, muss man im Prinzip nur eine Zeile hinzufügen/ändern:
<ModulePrefs title="Title of Your Application"> <Require feature="opensocial-0.5"/> </ModulePrefs>
Nun hat man Zugriff auf OpenSocial und kann es dann im Prinzip auch in Javascript nutzen. Diese Javascript-Funktionen fügt man dann im HTML-Code hinzu. Ein Beispiel kann so aussehen:
function onLoadFriends(dataResponse) { // do something with the dataResponse }
/**
* Request for friend information when the page loads.
*/
function getData() {
document.getElementById('message').innerHTML = 'Requesting friends...';
var req = opensocial.newDataRequest();
req.add(req.newFetchPersonRequest('VIEWER'), 'viewer');
req.add(req.newFetchPeopleRequest ('VIEWER_FRIENDS'), 'viewerFriends');
req.send(onLoadFriends);
};
Hier sieht man eine Anfrage an das Netzwerk, um Informationen über den Besucher der Seite (VIEWER) und seine Freunde (VIEWER_FRIENDS) zu bekommen. Es geht hier also nicht um den User, auf dessen Seite man ist, sondern es geht um den Besucher dieser Seite, so er denn auch im Netzwerk angemeldet ist.
Man sieht hier auch, dass man eine Callback-Funktion (onLoadFriends) angibt, denn der Request an das Netzwerk wird asynchron abgearbeitet.
Eine Callback-Funktion kann nun so aussehen:
/**
* Parses the response to the friend information request and generates
* html to list the friends by their display name.
*
* @param {Object} dataResponse Friend information that was requested.
*/
function onLoadFriends(dataResponse) {
var viewer = dataResponse.get('viewer').getData();
var html = 'Friends of ' + viewer.getDisplayName();
html += ':<br><ul>';
var viewerFriends = dataResponse.get('viewerFriends').getData();
viewerFriends.each(function(person) {
html += '<li>' + person.getDisplayName();
});
html += '</ul>';
document.getElementById('message').innerHTML = html;
};
Dieser Code-Schnipsel bekommt einen ‚dataResponse‘ übergeben und von dort kann man dann die vorher angefragten Daten extrahieren. So erhält man hier den Namen des Besuchers (viewer.getDisplayName()) und die Namen seiner Freunde in einer Schleife. Die Ergebnisse werden dann per DOM ins HTML integriert. Damit hätte man dann sein eigenes Gadget, was man auf irgendeiner OpenSocial-Site nutzen kann. Man sieht hier auch, dass Standards wie HTML und JavaScript genutzt werden.
Das unterliegende Netzwerk kann dabei im übrigen bestimmen, welche Funktionen erlaubt sind und welche nicht.
Eine Dokumentation zum Entwickeln von Containern gibt es leider noch nicht, da muss man noch etwas abwarten. Ein SDK dafür soll es dann auch geben und Hi5, einer der Launch-Partners von Google bei dem Projekt hat auch angekündigt, bei Veröffentlichung des SDK eine Open Source-Implementierung anzubieten.
Welche APIs gibt es?
Generell gibt es 3 APIs. Die erste wurde oben demonstriert und dabei geht es um Benutzer- und Profilinformationen. Die zweite API beschäftigt sich mit der persistenten Speicherung von Daten, denn Gadgets können auch Daten pro Benutzer speichern. Damit kann man z.B. komplett unabhängige Applikationen schreiben, die keinen eigenen Storage-Space benötigen.
Um auch auf die Aktivitäten von Benutzern zugreifen zu können (sowas wie auf Facebook im Profil), hat man die dritte API.
Genaueres muss ich dann wohl erstmal durch Ausprobieren und genaueres Lesen der API-Dokumentation herausfinden.
Offene Fragen
Nach der Präsentation auf dem Barcamp, die ich zusammen mit Lukas Rosenstock und David Recordon gemacht habe, gab es recht viele Fragen aus dem Publikum, von denen die meisten wohl nur Google beantworten kann. David hat die Fragen aufgeschrieben und auf seinem Blog veröffentlich, hier nochmal die Liste
- What is Google’s role in OpenSocial? Is OpenSocial actually open, or does the community need to build „OpenOpenSocial“?
- What does it take to make my site OpenSocial friendly? How do things like Microformats and FOAF relate?
- How can I support OpenSocial APIs (e.g. get friends) without allowing the applications to be run directly on my site?
- How does or will OpenSocial address social network portability?
- How will OpenSocial application management evolve. Will it really be „write once, run everywhere“ or will different containers impose policies that cause an application to still need container specific programming. For example, container A gives 5mb of data storage whereas container B only gives 100kb.
- How will OpenSocial impact spam and abuse? Will it become more prevalent in a distributed fashion?
- How does data storage work? Can an application share data between containers?
- How does OpenSocial address internationalization issues?
- What Google products is OpenSocial going to create? Why did they do it beyond just disrupting Facebook?
- How does OpenSocial work with mobile?
- What business model changes will adoption of OpenSocial lead to?
Vieles davon ist noch offen, vor allem Google’s Rolle. Es scheint auch unklar zu sein, ob denn immer ein Google-Server im Setup vorhanden sein muss, ich denke aber nicht. Gadgets kann man meines Wissens selbst hosten und der Container (also die Plattform, die das Gadget hostet) sollte auch unabhängig sein und muss nur die OpenSocial-API implementieren (die auf gData aufsetzt).
Wie steht Open Social zum Social Graph
Der Begriff „Social Graph“ kommt so langsam in Mode und im Prinzip geht es darum, dass man seinen eigenen Social Graph (also seine Freunde/Kontakte und deren Freunde usw.) wieder selbst „besitzt“. Im Moment hat fast jedes Social Network eine eigene Liste von Kontakten pro User. Dies macht wenig Sinn, vor allem für den User. Daher gibt es in der Web-Community (David ist z.B. Teil dieser Diskussion und das ist wohl auch sein Thema bei Six Apart) eine wachsende Bewegung, einen Standard zu schaffen, so dass diese Informationen wieder exportiert bzw. aggregiert werden können. Brad Fitzpatrick (jetzt Google) und David haben dazu ein Paper geschrieben, was recht lesenswert ist.
Die Hoffnung war nun (da ja auch Brad jetzt bei Google ist), dass Open Social in diese Richtung geht. Dies scheint jedoch nicht der Fall zu sein. Die größte Erleichterung wird hier sicherlich für den Entwickler und nicht für den Benutzer geschaffen. Rein theoretisch könnte man natürlich eine Applikation schreiben, die dann von jedem sozialen Netzwerk die Freunde extrahiert und dann zentral irgendwo speichert, aber das wird wohl meist gegen die Terms of Service sein (was seltsam ist, denn ist es denn nicht mein social graph?!?)
Diese Hoffnung hat sich also nicht wirklich erfüllt, aber die Gruppe hier auf dem Barcamp war sich dennoch einigermassen sicher, dass es ein (wenn auch kleiner) Schritt in die richtige Richtung ist.
Wie dem auch sei, es bleibt abzuwarten. Ich denke mal, dass im Moment mehr Hype da ist, als gerechtfertigt ist, denn es ist im Endeffekt ja doch nur eine Möglichkeit, plattformübergreifende Applikationen zu entwickeln, so dass bald jede Website ihre eigene Vampire-Applikation hat, um ihre Benutzer zu nerven ;-)
Tags: opensocial, google, bcb2, barcampberlin2, berlin, sixapart, hi5, api, entwicklung, mrtopf