On Mon, May 28, 2012 at 12:45 PM, Ate Douma <[email protected]> wrote: > On 05/26/2012 06:26 AM, Chris Geer wrote: > >> On Fri, May 25, 2012 at 8:00 PM, Franklin, Matthew B. >> <[email protected]>wrote: >> >> On 5/25/12 4:54 PM, "Chris Geer"<[email protected]> wrote: >>> >>> To prod along the conversation about modularization and architecture I >>>> wanted to pick one thing and try and talk through it before moving onto >>>> bigger things. Right now Rave has a core data model defined in >>>> org.apache.rave.portal.model which are all concrete JPA classes. To >>>> support >>>> pluggable persistence layers we will need to migrate the definitions to >>>> interfaces and move the JPA implementations to a JPA module. Assuming >>>> that >>>> is an agreed upon task I have a couple questions: >>>> >>> >>> +1. Took the words out of my mouth :). Initially a few of us pushed >>> pretty hard for the pojo programming model as a shorter entry point, but >>> in retrospect, we should have just gone with interfaces as others >>> suggested. As part of the roadmap discussion, I was going to propose >>> this >>> very thing on the wiki. I was going to propose we do this in a branch, >>> like we did with Bootstrap. >>> >>> >> I agree, starting a branch to work on this is the right approach when we >> start. >> >> >>> >>> >>>> 1) Has any of this been done as part of the JCR activity? Is that still >>>> in >>>> progress? >>>> >>> >>> Ate? Unico? >>> >>> 2) I know we want to support multiple UI layers (OpenSocial, W3C...) but >>>> OpenSocial is the only one so far that defines a backend data structure >>>> as >>>> far as I know. With that in mind, does it make sense to consider using >>>> the >>>> Shindig data interfaces instead of rolling our own and having to >>>> translate >>>> between org.apache.rave.portal.model.**Person and >>>> org.apache.shindig.social.**opensocial.model.Person? Do we anticipate >>>> non-OpenSocial data models that compete with the OpenSocial one? >>>> >>> >>> We attempted to keep OS or Wookie dependencies out of the core so that we >>> can support the case where people don't actually run Rave with OpenSocial >>> support (IE Wookie only) or with a custom renderer and no Wookie or Rave. >>> >>> >> Conceptually, I agree with this but I wonder how different Rave Core can >> really be than OpenSocial and still meet compliance. At some point it >> becomes really painful. I guess my point of view (maybe selfishly) is that >> Rave shouldn't try to be everything to everybody (if someone needs a >> highly >> custom back end and doesn't want to use Wookie or OpenSocial are they >> really using Rave?) but should focus on being a kick butt OpenSocial >> server >> that also supports W3C gadgets (Or run only W3C gadgets with an OpenSocial >> backend since Wookie can work with the APIs). >> > > To be honest, right now I don't see much desire to support other Widget > like containers other than OpenSocial and W3C Widgets. However I do see > those two as critical to be supported both. > > I also think that you can't 'just' run W3C widgets with only an OpenSocial > backend. Wookie might support running OpenSocial gadgets (to some extend) > but also needs its own server/backend model as well. Which you will always > need for 'native' W3C Widgets. And running OpenSocial Gadgets via Wookie > through Rave doesn't make sense to me. It might be useful for a Wookie-only > setup, but not if you already have full OpenSocial support within Rave. >
When I was using the term "backend" here I was talking about the Social/Data part of OS, not the gadget rendering part. I thought I read somewhere that Wookie had support for accessing OS social/data APIs from it's W3C widgets. > > Ate > > >> >>> >>>> Chris >>>> >>> >>> >>> >> >
