I added it originally. We don't have any use case and UI support for social features (e.g. friends, activity streams). Currently, most of our work is related to gadget rendering and integration with Wookie. So I removed it from 0.1 release schedule.
Gerald On Tue, May 24, 2011 at 2:19 PM, Franklin, Matthew B. <[email protected]> wrote: > 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. >>>>> >>>>>> >>>>> >>>>> >>> >>> > >
