On 5/18/11 12:06 AM, "Zhenhua (Gerald) Guo" <[email protected]> wrote:
>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. I think we need to make a decision as to whether Rave is going to be an OpenSocial container that can render W3C widgets or is a widget mashup engine with support for OpenSocial, W3C and other widget frameworks. This decision will help us decide to what degree we depend on Shindig. My current thinking is that Rave manages the core data (people, widgets, pages, etc) and it gets re-exposed via the rendering engines. This means you *could* deploy rave with no OpenSocial support and only W3C or vice-versa. >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. >> >>> >> >>
