>-----Original Message----- >From: Chris Geer [mailto:[email protected]] >Sent: Saturday, May 26, 2012 12:27 AM >To: [email protected] >Subject: Re: Modularization > >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).
Most of the of OpenSocial that the Rave core would need to be aware of (at least initially) are actually externalized specs: Portable Contacts & ActivityStreams. I agree translation is not fun though... One big thing to think about in this same space is field support. OpenSocial doesn't require much and we would need a simple way to define what fields Rave & Rave-Shindig support. > >> >> > >> >Chris >> >>
