OpenSocial Support for Ringside Social Application Server
Background:
OpenSocial is an alternative social application development environment to FaceBook. It varies from Facebook in that a far larger amount rendering work is performed in your web browser than on the server. Most of the role of a canvas disappears and it is up to the browser to make OpenSocial api calls and then interpret the results to form HTML snippets at document load time. This is because OpenSocial is based on the Google Gadgets API and treats all of its social apps as gadgets. Essentially this makes OpenSocial = Google Gadgets + REST web service based social API + ATOM Feeds.
To learn more about OpenSocial go to http://code.google.com/apis/opensocial/, or take a look at our own architecture overview.
There is an Apache project which provides a file based implementation of OpenSocial called Shindig (http://incubator.apache.org/shindig/). Shindig provides an implementation of the JavaScript engine required to load the Gadget XML definition (Gadget Specification) and make OpenSocial API calls.
Shindig also provides implementations of the Web Service back end API for OpenSocial in both Java and PHP.
Architecture:
OpenSocial's REST API's revolve around some basic objects with can be mapped into equivalents in the Ringside schema.
These are the basic object types OS manipulates:
1 People - Equivalent to profile information about a user.
2 Relationships - Person a is friends with person b.
3 Activities - Represents events generated by the user. What our friends are doing when you are not online.
4 Persistence - Saved Application state data.
5 Views - Equivalent to ringside Flavors used to control how an gadget is rendered based on the location or context is is being rendered in.
In the Shindig implementations these use a file based repository to store and retrieve their results.
Below is a pseudo code description of the data structures we eill need to integrate into our data model to store Open Social Data.
Proposed Integration:
1. Shindig's Javascript client and gadget rendering engine should be copied as is to the API public folder. This client should not need to be modified since the concept of more than one OS server is built into the client.
2. The PHP File based OS API should be installed into the API layer as a new endpoint. 
3. A set of API Unit tests should be developed to test the existing OS API. These tests and any cnahnges we might make to the Shindig API should be contributed back to Google.
4. This test suite should be automated.
5. The persistence code for the current OS/Shindig implementation should be transfered to the new Data Object Layer. This should result in a DB/Model neutral implementation of OS. This would also allow OS to read from the Ringside DB schema while continuing to pass the file based unit tests.
6. Authentication for Shindig is almost identical to Facebook's authtoken based system. Authentication should be integrated into our own Login.php.
7. Atom Feed support would be deferred until the next release.
8. A trail map would be produced that demonstrated the hello world gadget running from a Ringside server displaying user data which could also be edited using the facebook API. Other tutorials would be pointed to on Google's OS site.