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). > > > > >Chris > >
