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