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