On 28 May 2012, at 21:59, Chris Geer wrote: > 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.
Yes, its not really up to date, but we can in principle inject OSAPI features into W3C Widgets, and we have some proof-of-concept code for that in the Wookie scratchpad area. However there is no back-end for this, we'd just delegate it to the Rave container. > >> >> Ate >> >> >>> >>>> >>>>> Chris >>>>> >>>> >>>> >>>> >>> >>
