On 28 May 2012, at 21:55, Chris Geer wrote: > 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.
Thats correct, Preferences is the only required feature with some kind of data backend. Wookie also provides an implementation of the Wave Gadget API spec as a Wookie feature, including backend. > 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 >>> >>> >>
