Just committed code for initial SPI implementation (JPA is used). Based on response in previous emails, I put the code into rave-shindig. Current user table is not used at all because it's more a user management oriented object. Instead a table "person" (with some other tables) is created for storing information of OpenSocial persons.
@Matt It's a good idea to create unified REST services accessed by both Shindig and portal. However, if Opensocial REST services are enough (don't need other services), the unified REST service layer may not be necessary. If we need more services than those provided by OpenSocial spec, we can either extend OpenSocial, or as you said, build another layer encapsulating OpenSocial services and other services. Above considerations are based on my knowledge about gadgets and OpenSocial. To support other types of widgets (e.g. W3C widget), probably more careful investigation is required. @Ate I talked with Marlon about data access component. Besides what you proposed (writing separate database access module), another strategy is that all database accesses, not only OpenSocial data accesses but also RAVE portal data acceses, are delegated to Shindig. For example, when user logs in RAVE portal, a request is sent to portal to get user's layout data. This request is received by portal and data access request is sent to Shindig. In other words, all data is managed by Shindig. To do so, OpenSocial data objects need to be extended to include RAVE portal data. For example, Person object can be extended to include 1) the user's portal layout data 2) the user's gadget preferences 3) more authenticated information, etc. It may or may not work well in reality. Just my (and Marlon's) 0.02 cents. Gerald On Mon, May 16, 2011 at 1:22 PM, Franklin, Matthew B. <[email protected]> wrote: > On 5/13/11 11:33 AM, "Ate Douma" <[email protected]> wrote: > >>Another benefit I forgot to add of creating a separate database access >>module >>would be that it allows creating other (portal independent) applications >>like an >>admin console for maintenance purposes or reporting solutions which don't >>need >>and possibly even are undesired to be integrated directly in the portal. >>Of course, for that we could also add an additional REST or RPC services >>layer >>within the portal (and we also can do both), but for low-level/admin >>usage a >>direct database access layer probably might be easier and preferred. > > This sounds similar to the approach that Jesse took internally for OSEC > (unless I am misreading the comments). He created a backend person REST > service that both Shindig and OSEC connect to. > > Given that Rave is going to be integrating multiple widget renderers, it > might make sense to build a central component that manages the data store > for information (like person) that is common amongst all components, then > provide an API for access by Shindig, portal and Wookie. > >> > >
