On Fri, Mar 1, 2013 at 4:55 PM, Erin Noe-Payne <[email protected]>wrote:
> 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? > Good question. Part of that will depend on the dependencies between the entities. I think the core should contain everything to handle widgets/pages at a minimum. If we decide Person is moved out of core we need to decide if page sharing is based on Person or User. > > > > > > > > > > >> 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. > > >
