I currently works for the biggest domain registrant, website and blog hosting service in The Netherlands : mijndomein.nl, who got the idea that the web is better when it's social. And such i became the author of the PHP port of the Shindig project.
Shindig is a new project in the Apache incubator that is becoming the reference implementation for OpenSocial and gadgets infrastructure.This project aims to make it easy for a new social website to become a "container" for OpenSocial applications, and is making rapid progress.
The projects website lives here:Â http://incubator.apache.org/shindig/ and you can get the code from:
# svn co http://svn.apache.org/repos/asf/incubator/shindig/trunk/ shindig
And you can see it in action in a live version of partuza at:
http://partuza.chabotc.com
How to use shindig - quick overview using Partuza as an example:
The first thing to keep in mind is that an open social SNS (social networking site) has a few components:
A) The site it's self
B) The database / data source (social information, profiles, app data, media items, etc)
C) The gadget renderer (shindig)
D) The social data interface (shindig + your own code to connect it to B)
Now another thing to keep in mind is that security is an important issue, the security (that gadgets can't read or manipulate (A), the site, in a malicious manner ) is provided by the browser security model.
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).
The result of this is that you want your gadget renderer (the source domain for the gadget iframe content) on a different host then the site, else you don't have this security in place, and thats bad :)
However you do want your gadget to be able too:
1) Interact through a safe protocol to: resize it's content area, request a message to be send, request the app to be shared, change the title header above it, etc
2) Retrieve social information and set app data, create activities, etc
(1) is provided by the RPC service, there is a RPC channel (with implementations that work on all browsers) that create such a channel between the gadget and site, and the site implements these services through javascript and/or it's own wire format.
See:Â http://code.google.com/p/partuza/source/browse/trunk/html/js/container.js as an example of this (it does the basic services but not request_share_app or send message etc yet).
Another example (i think they do a few things them selves that shindig provides functionality for, but it's a good live example non the less):
http://www.hi5networks.com/platform/browser/shindig/features/opensocial-0.7/hi5container.js
(2) Is the social information.. now to be able to retrieve this it needs to be on the same domain as the gadget domain, this is why shindig has a social data interface (and soon also a RESTful service interface), so this is component (D)
In (D) / (2) you create your own data interface that connects to your own data sources, be it a data base connection, soap or xml-rpc interface, or whatever your infrastructure has .. I've done this for Partuza in:
http://code.google.com/p/partuza/source/browse/trunk/Shindig/PartuzaHandler.php
http://code.google.com/p/partuza/source/browse/trunk/Shindig/PartuzaDbFetcher.php
As you can see those implement the shindig standard interfaces on one side (handler), and connects to a simple db structure on the other side (db fetcher), shindig takes care of the rest (wire format interaction).
To configure php shindig which interface(s) to use, change the 'handlers' => '' configuration, and link (or copy) the interface files to src/php/social data, and you should be good to go.
I've used the metadata interface here since i want Partuza to be a 'simple example' on how to use shindig, and in a lot of ways this is the simplest way to hook gadget awareness up to your social site..
You could ofc have a copy of the shindig gadget rendering code on your SNS too, and do the same as the JsonRpcHandler does:
http://svn.apache.org/viewvc/incubator/shindig/trunk/php/src/gadgets/JsonRpcHandler.php?view=markup
As long as the shindig code is a straight copy, and you use the standard internal interfaces (so you can just update the shindig code to keep up with the new spec's etc), there is no problem doing that.
All in all there isn't such a big difference between the 2 methods, the first (using metadata) means you have to create a bit less code, and your SNS isn't dealing with the load of rendering gadgets to retrieve meta data, and the second one (rendering and retrieving the metadata inside the SNS) you lighten the load on the shindig server(s) a small bit. (though this is a negligible difference since shindig will have to retrieve and cache the gadget anyhow to render it). I currently works for the biggest domain registrant, website and blog hosting service in The Netherlands : mijndomein.nl, who got the idea that the web is better when it's social. And such i became the author of the PHP port of the Shindig project.
Shindig is a new project in the Apache incubator that is becoming the reference implementation for OpenSocial and gadgets infrastructure.This project aims to make it easy for a new social website to become a "container" for OpenSocial applications, and is making rapid progress.
The projects website lives here:Â http://incubator.apache.org/shindig/ and you can get the code from:
# svn co http://svn.apache.org/repos/asf/incubator/shindig/trunk/ shindig
And you can see it in action in a live version of partuza at:
http://partuza.chabotc.com
How to use shindig - quick overview using Partuza as an example:
The first thing to keep in mind is that an open social SNS (social networking site) has a few components:
A) The site it's self
B) The database / data source (social information, profiles, app data, media items, etc)
C) The gadget renderer (shindig)
D) The social data interface (shindig + your own code to connect it to B)
Now another thing to keep in mind is that security is an important issue, the security (that gadgets can't read or manipulate (A), the site, in a malicious manner ) is provided by the browser security model.
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).
The result of this is that you want your gadget renderer (the source domain for the gadget iframe content) on a different host then the site, else you don't have this security in place, and thats bad :)
However you do want your gadget to be able too:
1) Interact through a safe protocol to: resize it's content area, request a message to be send, request the app to be shared, change the title header above it, etc
2) Retrieve social information and set app data, create activities, etc
(1) is provided by the RPC service, there is a RPC channel (with implementations that work on all browsers) that create such a channel between the gadget and site, and the site implements these services through javascript and/or it's own wire format.
See:Â http://code.google.com/p/partuza/source/browse/trunk/html/js/container.js as an example of this (it does the basic services but not request_share_app or send message etc yet).
Another example (i think they do a few things them selves that shindig provides functionality for, but it's a good live example non the less):
http://www.hi5networks.com/platform/browser/shindig/features/opensocial-0.7/hi5container.js
(2) Is the social information.. now to be able to retrieve this it needs to be on the same domain as the gadget domain, this is why shindig has a social data interface (and soon also a RESTful service interface), so this is component (D)
In (D) / (2) you create your own data interface that connects to your own data sources, be it a data base connection, soap or xml-rpc interface, or whatever your infrastructure has .. I've done this for Partuza in:
http://code.google.com/p/partuza/source/browse/trunk/Shindig/PartuzaHandler.php
http://code.google.com/p/partuza/source/browse/trunk/Shindig/PartuzaDbFetcher.php
As you can see those implement the shindig standard interfaces on one side (handler), and connects to a simple db structure on the other side (db fetcher), shindig takes care of the rest (wire format interaction).
To configure php shindig which interface(s) to use, change the 'handlers' => '' configuration, and link (or copy) the interface files to src/php/social data, and you should be good to go.
I've used the metadata interface here since i want Partuza to be a 'simple example' on how to use shindig, and in a lot of ways this is the simplest way to hook gadget awareness up to your social site..
You could ofc have a copy of the shindig gadget rendering code on your SNS too, and do the same as the JsonRpcHandler does:
http://svn.apache.org/viewvc/incubator/shindig/trunk/php/src/gadgets/JsonRpcHandler.php?view=markup
As long as the shindig code is a straight copy, and you use the standard internal interfaces (so you can just update the shindig code to keep up with the new spec's etc), there is no problem doing that.
All in all there isn't such a big difference between the 2 methods, the first (using metadata) means you have to create a bit less code, and your SNS isn't dealing with the load of rendering gadgets to retrieve meta data, and the second one (rendering and retrieving the metadata inside the SNS) you lighten the load on the shindig server(s) a small bit. (though this is a negligible difference since shindig will have to retrieve and cache the gadget anyhow to render it). 