Sounds good. Thanks Gerald. -Matt
On 5/26/11 4:54 PM, "Zhenhua (Gerald) Guo" <[email protected]> wrote: >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. >>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >> >>
