On Monday, May 28, 2012, Ate Douma wrote: > On 05/25/2012 10:54 PM, Chris Geer 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) Has any of this been done as part of the JCR activity? Is that still in >> progress? >> > Yes, that still is in progress, or maybe better said in progress getting > started :) > Unico made a first start with initial JCR bootstrap and initialization > features, but he's been on holiday the last 3 weeks (back by tomorrow). > Ard joined the effort last week by picking up work on the Jackrabbit JCR > OCM module (so within the Jackrabbit project) to get it ready to be used > for Rave. > The timing of separating out the JPA persistence layer now is perfect in > that respect. I expect that in a few weeks time we could start on a partial > JCR based back-end for Rave Portal. > And Marijan and myself hope to get started with the 'real stuff' > concerning content services as well as a HMVC model and layer for the > portal site and page management sometime in June. > At Hippo we had some business distractions in April with as result that > the initial planning and availability for our Rave contributions no longer > was valid. We're scheduling this in again ASAP, but it'll take a bit more > time now. > > 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. >> > I think OpenSocial doesn't even define a backend data structure, Shindig > does. > And the same goes for W3C Widgets, while Wookie does have a back-end model. > The real difference IMO is that Shindig provides an abstract model/SPI > while Wookie does not. Yet...
I'm definitely not a W3C gadget expert but the only "data backed" I see in the specs is for storage of preferences [1]. This differs from OpenSocial since they define the Core/Social API and Data specs which define things like Person, Activity, Group... [2]. I didn't see a similar construct in W3C. I agree they each have a unique rendering backed but I was referring to more the user/social aspects. [1] http://www.w3.org/2008/webapps/wiki/WidgetSpecs [2] http://docs.opensocial.org/display/OSD/Specs > > What I've suggested before is the option to modularize Wookie a bit > further and see if we can come up with a separate backend model/SPI for > Wookie as well. > Of course that is a discussion for the Wookie project itself, but IMO it > is something which would benefit both Wookie and help with a much better > integration and support within Rave. > > Regardless however if we can get/add a Wookie model/SPI, I think there is > a difference between the data model(s) needed for Widget Containers > (Shindig/Wookie/...) and the data model needed for the Rave Portal. > To me a OS Person != Rave User > And even much more explicit: a OS Group != Rave Group At some point there needs to be a link between a Rave user and an OS person representation (at least when runnin OS backend). That relationship could be modeled several ways but it simplifies things if a Rave user is a superset of OS Person and even implemented the Shindig Person interface to avoid translating between objects. At the very least, to support the social APIs in OS we need to be able to process/persist OS data. I fully understand that if you are running a Wookie front end and don't need social data you won't need a full blown Person object. The big question in my mind though is how is that actually implemented. In Rave, is the OS data model (Person, Activity..) truly optional such that you can choose uninstall that module and not have that data in your DB? Or is the OS data model part of Rave but it just might not be fully used in some implementations? Using Person as the example, is there a Rave Person table that has all the fields to fully represent an OS Person and unused fields are just left blank/null or is there a Rave Person table that is bare minimum and then a OS Person table that links back to the Rave Person table (and maybe a Wookie Person table...)? Maybe our short term task while talking modularization is to draw out the Rave data model and how it supports OS data or what additional objects are required beyond the core Rave model to fully support OS data. Maybe a starter question so that I'm on the same page as everyone. Does Rave intend to be compliant with the full OpenSocial specification or just the OpenSocial gadget spec? > > 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? >> > > If Wookie could get an backend model/SPI, it might be very beneficial to > consider (re)using part of the Shindig model where applicable, of course > not so much in API but in model definition and entity naming/concepts. > Other than that, I think it doesn't or shouldn't really matter for as much > as it only concerns each separate Widget Container model. > > With respect to the Rave Portal model I don't see how we can or even need > to consider competing data models. > > Ate > > >> Chris >> >> >
