On Fri, Mar 1, 2013 at 6:10 PM, Matt Franklin <[email protected]>wrote:
> On Fri, Mar 1, 2013 at 6:02 PM, Chris Geer <[email protected]> wrote: > > Erin, thanks for putting this together. My thoughts are in-line below. > > > > On Fri, Mar 1, 2013 at 3:16 PM, Erin Noe-Payne <[email protected] > >wrote: > > > >> One of the major discussions at the ApacheCon Rave Hackathon was > decoupling > >> the rave core from the rave portal. This is meant as a proposal / > kick-off > >> discussion about where to divide the two. > >> > >> Rave Core: > >> - Manages the data repository APIS. > >> - Javascript libraries to interact with apis, manage providers and > provide > >> widget functionality. > >> - Does not implement views or controllers. > >> - Should be deployable independently of the portal. > >> > >> Rave Portal: > >> - Web application implementing a portal on top of rave core. > >> - Provides a widget store, activity streams, and pages - the > functionality > >> we currently see when we download rave. > >> > >> Questions: > >> Are users / persons part of the rave core, or are they specific to the > >> portal? > >> > > > > Users should be part of core, I'm not sure about Person. We might want to > > have a way to add modules to the core to extend the APIs independent of > the > > portal. > > +1 +1 for extensible APIS. To phrase differently then, what models / relationships do we have in rave now that we do not see core managing? Friends, page sharing, page templates...widget comments, tags, ratings? > > > > > >> Should we branch or push incremental changes into trunk? > >> > > > > I think we should start incrementally. I'm going to create a first cut at > > the new api layer (independent of what is there now). Then we can see how > > we integrate with it. Maybe the new JS side talks with the new API as > it's > > rolled out. > > > > +1 > Yes. As the api rolls out it will be easy to integrate with JS api seamlessly (in theory). > > > > >> How much / little should the rave core do? On the server - anything more > >> than rest apis? On the client - make any assumptions about views / > markup > >> structure or expect to be handed dom elements for rendering? > >> I'm especially interested in on Ate's take on this from the perspective > of > >> being useful for Hippo & HMVC. > >> > > > > Deployment question - is the core layer always deployed independently or > do > > we bundle it with the portal? > > I think we start with the assumption that the core is embedded in the > integrating webapp, in the case of the demo this becomes the portal. > In the event that someone wants to spin up a standalone core instance, > we should have a maven archetype that sets up a webapp around the > core. >
