There are two ways how Shindig SPIs are implemented. 1) Implementation of Shindig SPI directly accesses RAVE database to get whatever information it needs. Disadvantages: - Shindig and RAVE portal must be placed on the same machine. - Database access code may be duplicated in both Shindig SPI implementation and RAVE code.
2) RAVE portal exposes OpenSocial services (e.g. GetPerson, GetAlbums) and implementation of Shindig SPI calls them (instead of accessing database directly). Advantages - Shindig and RAVE portal can be run on separate machines - Database access code is maintained in only one place. Disadvantages: - Security concern may arise. Any comments about which one is better? Gerald On Tue, May 10, 2011 at 11:42 PM, Zhenhua (Gerald) Guo <[email protected]> wrote: > I just created a JIRA sub-task for OpenSocial Person related SPI > implementation. > The Person object is specified in OpenSocial spec 2.0 > http://opensocial-resources.googlecode.com/svn/spec/2.0/Social-Data.xml#Person. > In RAVE, we have already had User class. However, our existing User > class serves different purposes than OpenSocial Person object. > I am considering implementing Person related SPIs, at least GetPerson > SPI, if nobody else is implementing it. In the first step, I will use > our existing User class and expose basic user information (e.g. > username) to Shindig. Then I will extend User class (or write a > completely new class) to add more fields required by OpenSocial Person > data structure/model. > Any comments on this? Is the proposed implementation strategy appropriate? > > Thanks, > Gerald >
