Where do we stand on the SPI implementation? Are they good to go for the first release? I haven't seen any of the SPI issues get updated in JIRA and from looking around the archives, I think there were still some open questions.
Since someone added the issues to the 0.1 release schedule, I think we either need to make sure they get done, or pull them off and put them in the next release. -Matt On 5/18/11 12:00 PM, "Zhenhua (Gerald) Guo" <[email protected]> wrote: >Probably some experts from both worlds can clarify to what extent >OpenSocial data models and W3C widget data models differ. It may >bring difficulties if data models from different standards cannot be >easily mapped. However, I would image they are similar more or less. >Anyway, I think it's a good idea to have a separate independent >"social data store" module, which exposes REST services that can be >called by whatever clients (e.g. OpenSocial, W3C Widget). Then we >have unified data models and data access module. > >Gerald > > >On Wed, May 18, 2011 at 9:38 AM, Franklin, Matthew B. ><[email protected]> wrote: >> 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. >>>> >>>>> >>>> >>>> >> >>
